Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

<hs
Hallo <supraracer

Habe ich das Richtig verstanden dieser Eintrag kommt in die Oscam.server vom Client ?
[reader]
label = server_cs357x
protocol = cs357x
device = 192.168.100.90,54321
user = user2
password = passwd2
fallback_percaid = 098C;1830
group =1

muss nicht auch das Protokoll
cs 357x auch in die Oscam.conf vom Server
wird beim Server gar nichts eingetragen?

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Hi,

auf dem Server brauchst du natürlich die passenden Ports zum Protokoll. Aus dem Beispiel aus #1

-supraracer

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

müssen die Ports dabei verschieden sein oder können die auch gleich sein?

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Die müssen verschieden sein.

-supraracer

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Hi,
@supra,
ich glaub, das müssen sie nicht.
Da das eine UDP und das andere TCP ist, müsste es auch mit dem gleichen Port klappen.

Gruß
janni1

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

können die gleichen sein, habe ich auch so konfiguriert zum Testen im HS

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Ich gestehe Lesefaulheit ein und hoffe es hat noch keiner die Frage gestellt:
Warum sollte man bei einer zeitkritischen Anwendung auf einem unzuverlässigen Transportmedium überhaupt TCP verwenden?

Ich habe alles auf UDP (cs357x) umgestellt und fahre damit deutlich besser. Wenn keine Probleme in der Leitung auftreten, macht es keinen Unterschied, ob man UDP oder TCP verwendet. Wenn Verbindungsprobleme beim CS auftreten, wird man sowohl bei TCP als auch bei UDP in einen Freez rennen. Im LAN mag TCP evtl. noch gerade genug Zeit haben das Paket neu zu fordern, damit es keinen Hänger gibt. Aber spätestens über das Internet sind bei V14 karten die Latenzen zu hoch, als dass TCP da noch was retten kann. Im Gegenteil, der Freez wird mit TCP vermutlich sogar länger und heftiger sein. Beispiel:
Client fordert einen Key1 an, Paket von Key1 geht verloren, Client braucht schon einen neuen Key2, da das Paket von Key1 noch vermisst wird, hängt die Anfrage für Key2 im TCP-Stack fest, jetzt wird der Verlust von Paket von Key1 festgestellt, Paket von Key1 wird neu angefordert, Paket von Key1 wird verschickt, Client fordert schon Key3 an, Paket mit Key1 kommt endlich beim Client an, doch zu spät, jetzt wird erst das Paket von Key2 bearbeitet, der Key aber auch schon veraltet ist und eigentlich auch nicht mehr gebraucht wird, muss unnützer weise diese Anfrage auch noch beantwortet werden und es tritt noch mehr Verzögerung ein. In dem Beispiel wurden jetzt schon zwei Keys verpasst, das sind schon ein paar Sekunden Bild, das nicht beim Client entschlüsselt wurde.
Bei UDP würde es wie folgt ablaufen (wenn sauber Implementiert): Paket mit Key1 geht verloren, 1-2 Sekunden freeez, Client braucht Key2, Key2 Paket kommt an und wird sofort vom Server bearbeitet und beantwortet, Client kann jetzt schon wieder schauen. Sollte das Paket zu Key1 doch noch irgendwann aus den unendlichen Weiten des I-Net ankommen, wird es verworfen. Sprich man hat hier nur den Freez zu dem Zeitraum des Key1

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Ich gestehe Lesefaulheit ein und hoffe es hat noch keiner die Frage gestellt:
Warum sollte man bei einer zeitkritischen Anwendung auf einem unzuverlässigen Transportmedium überhaupt TCP verwenden?

Zum Vergrößern anklicken....

Aber #1 hast du wenigstens gelesen? Hier geht es nicht um Pro/Contra TCP+UDP, du kannst die Reader auch einfach drehen und den TCP als Fallback nehmen.

Ich habe alles auf UDP (cs357x) umgestellt und fahre damit deutlich besser. Wenn keine Probleme in der Leitung auftreten, macht es keinen Unterschied, ob man UDP oder TCP verwendet. Wenn Verbindungsprobleme beim CS auftreten, wird man sowohl bei TCP als auch bei UDP in einen Freez rennen.

Zum Vergrößern anklicken....

Wo wurde etwas anderes behauptet?

Im LAN mag TCP evtl. noch gerade genug Zeit haben das Paket neu zu fordern, damit es keinen Hänger gibt. Aber spätestens über das Internet sind bei V14 karten die Latenzen zu hoch, als dass TCP da noch was retten kann. Im Gegenteil, der Freez wird mit TCP vermutlich sogar länger und heftiger sein.

Zum Vergrößern anklicken....

Im Topic dieses Thema steht explizit HS

Beispiel:
Client fordert einen Key1 an, Paket von Key1 geht verloren, Client braucht schon einen neuen Key2, da das Paket von Key1 noch vermisst wird, hängt die Anfrage für Key2 im TCP-Stack fest, jetzt wird der Verlust von Paket von Key1 festgestellt, Paket von Key1 wird neu angefordert, Paket von Key1 wird verschickt, Client fordert schon Key3 an, Paket mit Key1 kommt endlich beim Client an, doch zu spät, jetzt wird erst das Paket von Key2 bearbeitet, der Key aber auch schon veraltet ist und eigentlich auch nicht mehr gebraucht wird, muss unnützer weise diese Anfrage auch noch beantwortet werden und es tritt noch mehr Verzögerung ein. In dem Beispiel wurden jetzt schon zwei Keys verpasst, das sind schon ein paar Sekunden Bild, das nicht beim Client entschlüsselt wurde.
Bei UDP würde es wie folgt ablaufen (wenn sauber Implementiert): Paket mit Key1 geht verloren, 1-2 Sekunden freeez, Client braucht Key2, Key2 Paket kommt an und wird sofort vom Server bearbeitet und beantwortet, Client kann jetzt schon wieder schauen. Sollte das Paket zu Key1 doch noch irgendwann aus den unendlichen Weiten des I-Net ankommen, wird es verworfen. Sprich man hat hier nur den Freez zu dem Zeitraum des Key1

Zum Vergrößern anklicken....

Schön auf dem Reißbrett erklärt, gerne zitiere ich dich doppelt: "Wenn Verbindungsprobleme beim CS auftreten, wird man sowohl bei TCP als auch bei UDP in einen Freez rennen." Deine Erklärung stimmt aber eh nur teilweise, am besten liest du #1 nochmal in Ruhe durch.

-supraracer

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Das sollte keine Kritik o.ä. sein. Kern war meine Frage:

Warum sollte man bei einer zeitkritischen Anwendung auf einem unzuverlässigen Transportmedium überhaupt TCP verwenden?

Zum Vergrößern anklicken....

Vllt. habe ich ja was übersehen oder falsch verstanden, warum TCP die bessere Wahl wäre. Der Rest war nur zur Darstellung meiner Sichtweise, damit man mich ggf. korrigieren kann. Plus ein kleiner Blick über den Tellerrand, da einige dein Fallback-System sicher auch blindlings übers I-Net benutzen würden und sich dann wundern.

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Ich habe es auch nicht als Kritik verstanden, aber es muss nicht immer jedes Topic OT abdriften oder ein Laberthema draus werden.
Trotzdem nochmal: Es wurde hier doch gar nicht behauptet, dass TCP für HS unbedingt besser ist. Worauf du jetzt genau hinaus willst ist mir nach wie vor nicht klar, du widersprichst dir teilweise selbst in aufeinanderfolgenden Sätzen:

Ich habe alles auf UDP (cs357x) umgestellt und fahre damit deutlich besser. Wenn keine Probleme in der Leitung auftreten, macht es keinen Unterschied, ob man UDP oder TCP verwendet. Wenn Verbindungsprobleme beim CS auftreten, wird man sowohl bei TCP als auch bei UDP in einen Freez rennen.

Zum Vergrößern anklicken....

-supraracer

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Bitte Post ganz lesen:

Ich habe alles auf UDP (cs357x) umgestellt und fahre damit deutlich besser. Wenn keine Probleme in der Leitung auftreten, macht es keinen Unterschied, ob man UDP oder TCP verwendet. Wenn Verbindungsprobleme beim CS auftreten, wird man sowohl bei TCP als auch bei UDP in einen Freez rennen. [...] der Freez wird mit TCP vermutlich sogar länger und heftiger sein.

Zum Vergrößern anklicken....

Ich wiederhole mich gerne: Die Frage bleibt, wozu überhaupt TCP verwenden? Ich würde gerne verstehen, ob es einen tieferen Sinn hat, dennoch auf TCP zu setzen, den ich evtl. übersehe? Mit deinen Settings würde der Fallback ja nach 300ms einspringen, also wenn man schon einen Hänger im Bild hat. Mit UDP würde man erst gar keinen Fallback brauchen? Denn es würde automatisch sowieso bei nächsten ECM der neue Key erfragt.

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Hi,
@scotty

Mit deinen Settings würde der Fallback ja nach 300ms einspringen, also wenn man schon einen Hänger im Bild hat.

Zum Vergrößern anklicken....

Hat man bei 300ms schon einen Hänger bei einer V14?

Ich glaub du hast die ganze Fallback-Geschichte nicht richtig verstanden.

Alls erstes mal ganz allgemein vereinfacht gehen wir von einer CW-Gültigkeit von 7-10 sec aus.
Die ECM wechselt demnach auch aller 7-10 sec.

Wir senden nun beim ECM-Wechsel per TCP/UDP eine ECM auf die Reise zur Karte.
Falls nun die Antwort -warum auch immer- länger als hier 300ms dauert, schicken wir einfach auf gut Glück diese eine Anfrage nochmal hinterher, in der Hoffnung, dass diese nun ankommt, falls die erste irgendwo "verreckt" ist.
Auf welche dieser beiden Anfragen wir nun eine Antwort bekommen ist egal. Die sind sowie so gleich, denn dieses CW ist noch mindestens 6 -9 sec gültig.

Deshalb kann ich diesem Beispiel hier von dir nicht folgen
Was ist hier key1 und was key2, bis hin zu key3. In welchem Zeitraum spielt sich das in deinem Bsp. ab?
Das würde hier bedeuten, dass es eine ca. 30sec- Freezer gegeben hätte. (3 x ca. 10sec ECM/CW- Zyklus)
Kannst du das bitte mal näher erklären.

Und wieso bräuchte man bei UDP keine Fallback? Da würde ganau so nach "clienttimeout" ein Timeout kommen bei eine nicht zugestellten Anfrage/nach eine nicht eingetroffenen Antwort.

Gruß
janni1

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Also ich habe bei meiner V14 bereits Bildstörungen/Hänger bei einer Latenz von 200-300ms, demnach würde das Bild bereits hängen, bis der Fallback zündet.

Aber mit der Gültigkeit der ECM von 7-10sec hast du natürlich recht, genau da habe ich meinen Denkfehler. Da macht TCP wirklich wieder Sinn, dort hat man vllt nur 1-2sec einen Aussetzer, bis ein verlorenes Paket erneut zugestellt wird, und mit UDP wäre der ganze Zeitraum verloren, falls das Paket verloren geht. Mit dem Fallback kann man dann die 1-2sec auch noch etwas verkürzen.

Danke für die Info!

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Da passt was in deiner Config nicht, die V14 freezt noch nicht bei 300ms, bei 200ms schon gar nicht.

-supraracer

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Oder seine oscam Version ist zu alt.
Glaub ab ca 95 er Version müßtedas sein, das V14 freetz beseitigt wurde.