Karate01
Hacker
Es ist sicher nichts neues, aber es war glaube ich ein bisschen in Vergessenheit geraten.
Als Quelle diente mir das Internet.
Da habe ich an verschiedensten Stellen Informationen gefunden, die ich hier ein bisschen zusammen tragen wollte.
Zusammen mit meinen eigenen Erkenntnissen, hilft dieser Beitrag hoffentlich vielen Usern.
Problemstellung bei mir: Ruckler bei HD+
Anfangssituation bei mir
Ein Vergleichs-Test-Aufau
Ein zweiter Vergleichs-Test-Aufbau
==> Unterschied zwischen diesen Testsituationen: Das Internet und der Protokoll-Typ
Eigentlich wäre die Lösung damit ja schon da gewesen:
Zwar OSCAM benutzen, aber als Protokoll eben das "cccam-Protokoll" verwenden.
Klar wollte das nicht die erste Lösung sein.
Ein "älteres" Protokoll von der "Erzrivalen-CAM" .... das geht nicht.
Also war der zweite Lösungsansatz:
"camd35" müsste die gleichen Eigenschaften haben - was die Ausfallsicherheit angeht - wie das cccam-Protokoll.
Also musste man doch nur "camd35" als TCP-Variante nutzen.
Und hier kam das Internet als Informationsquelle ins Spiel.
Das gibt es alles bereits.
"camd35" kann von OSCAM entweder als [UDP]-Variante oder als [TCP]-Variante eingesetzt werden.
Man muss nur in den config-Dateien zwei Kleinigkeiten ändern.
Das muss beim Server in der OSCAM.conf drin stehen:
Und das muss beim Client in der OSCAM.server drin stehen:
==> Somit können wir die OSCAM benutzen und das aktuellere camd35-Protokoll und haben eine absolut stabile Verbindung.
Hinweis:
Natürlich muss auch die Portweiterleitung im Router auf "TCP" stehen und nicht mehr auf "UDP".
Ergebnis:
Kurz zur Erklärung:
(Die absoluten IT-Freaks mögen mir so manche Wortwahl und vereinfachte Darstellung verzeihen. Wenn wirklich grobe Schnitzer in meiner Erklärung drin sein sollten, könnt ihr mir ja eien Hinweis geben)
Bei UDP werden Anfragen gesendet OHNE zu überprüfen, ob die Anfragen angekommen sind.
Ich bezeichne das mal als "Fire-And-Forget"
Bei TCP werden Anfragen gesendet und es wird nachgefragt / sich vergewissert, ob die Anfrage auch wirklich komplett und verständlich angekommen ist.
Somit ein Protokoll, das Wert auf "Sicherheit" legt.
Messtechnisch ist dadurch natürlich das UPD "schneller" als das TCP.
Aber nach meinen Erfahrungen wirklich nur messtechnisch.
Ich habe bei den Antwortzeiten bei meinen Tests keinen signifikanten Unterschied gemerkt.
Und wenn, dann spielte sich das im 1/100 oder 1/10 Sekundenbereich ab.
--> Für mich war klar:
UDP ist zwar "schneller" als TCP - das ist für ganz viele das alles entscheidende Argument: Möglichst kurze Antwortzeiten (immer Rekorde brechen) - dem kann ich mich aber nicht anschließen !
TCP war immer noch rasent schnell und zudem eben auch "sicherer" - und das ist für mich das entscheidende Argument: Gute Antwortzeiten bei guter Sicherheit
Denn was bringen mir UDP-Bestzeiten, wenn es dann immer wieder zu Rucklern kommt, weil eben ab und zu die eine oder andere UPD-Anfrage eben NICHT am Ziel ankommt.
Ich könnte mir vorstellen, dass dies Erkenntnis vielleicht auch vielen anderen helfen könnte.
Und zwar den "WLAN" und "DLAN" geplagten Usern.
Auch hier kann ich es mir geradezu bildlich vorstellen, wie immer mal wieder, die eine oder andere "Fire-And-Forget"-Anfrage NICHT ankommt und es zu Freezer kommt.
Wenn aber immer nachgefragt wird, ob die Anfrage auch wirklich angekommen ist .....
==> Das ist wie gesagt momentan meine VERMUTUNG !!!
==> Hier habe ich keinerlei Erfahrungen gesammelt.
==> Aber vielleicht zeigen es ja die Rückmeldungen, ob ich mit dieser Vermutung richtig lag.
In diesem Sinne:
Viel Spaß beim Testen !
Als Quelle diente mir das Internet.
Da habe ich an verschiedensten Stellen Informationen gefunden, die ich hier ein bisschen zusammen tragen wollte.
Zusammen mit meinen eigenen Erkenntnissen, hilft dieser Beitrag hoffentlich vielen Usern.
Problemstellung bei mir: Ruckler bei HD+
Anfangssituation bei mir
--> Hier kam es bei den HD+ Kanälen immer wieder zu minimalen Rucklern / Freezern
Ein Vergleichs-Test-Aufau
--> Hier gab es keinerlei Schwierigkeiten. Keinerlei Ruckler. Keinerlei Freezer
Ein zweiter Vergleichs-Test-Aufbau
--> Auch hier gab es keinerlei Schwierigkeiten. Keinerlei Ruckler. Keinerlei Freezer
==> Unterschied zwischen diesen Testsituationen: Das Internet und der Protokoll-Typ
Eigentlich wäre die Lösung damit ja schon da gewesen:
Zwar OSCAM benutzen, aber als Protokoll eben das "cccam-Protokoll" verwenden.
Klar wollte das nicht die erste Lösung sein.
Ein "älteres" Protokoll von der "Erzrivalen-CAM" .... das geht nicht.
Also war der zweite Lösungsansatz:
"camd35" müsste die gleichen Eigenschaften haben - was die Ausfallsicherheit angeht - wie das cccam-Protokoll.
Also musste man doch nur "camd35" als TCP-Variante nutzen.
Und hier kam das Internet als Informationsquelle ins Spiel.
Das gibt es alles bereits.
"camd35" kann von OSCAM entweder als [UDP]-Variante oder als [TCP]-Variante eingesetzt werden.
Man muss nur in den config-Dateien zwei Kleinigkeiten ändern.
Das muss beim Server in der OSCAM.conf drin stehen:
Anstelle von
[cs357x]
port = 33033 (oder welcher Port auch immer)
kommt das rein
[cs378x]
port = 33044 (oder welcher Port auch immer)
[cs357x]
port = 33033 (oder welcher Port auch immer)
kommt das rein
[cs378x]
port = 33044 (oder welcher Port auch immer)
Und das muss beim Client in der OSCAM.server drin stehen:
Anstelle von
protocol = camd35
device = dyndnsname.org,33033
kommt das rein
protocol = cs378x
device = dyndnsname.org,33044
protocol = camd35
device = dyndnsname.org,33033
kommt das rein
protocol = cs378x
device = dyndnsname.org,33044
==> Somit können wir die OSCAM benutzen und das aktuellere camd35-Protokoll und haben eine absolut stabile Verbindung.
Hinweis:
Natürlich muss auch die Portweiterleitung im Router auf "TCP" stehen und nicht mehr auf "UDP".
Ergebnis:
--> Keinerlei Schwierigkeiten. Keinerlei Ruckler. Keinerlei Freezer
Kurz zur Erklärung:
(Die absoluten IT-Freaks mögen mir so manche Wortwahl und vereinfachte Darstellung verzeihen. Wenn wirklich grobe Schnitzer in meiner Erklärung drin sein sollten, könnt ihr mir ja eien Hinweis geben)
Bei UDP werden Anfragen gesendet OHNE zu überprüfen, ob die Anfragen angekommen sind.
Ich bezeichne das mal als "Fire-And-Forget"
Bei TCP werden Anfragen gesendet und es wird nachgefragt / sich vergewissert, ob die Anfrage auch wirklich komplett und verständlich angekommen ist.
Somit ein Protokoll, das Wert auf "Sicherheit" legt.
Messtechnisch ist dadurch natürlich das UPD "schneller" als das TCP.
Aber nach meinen Erfahrungen wirklich nur messtechnisch.
Ich habe bei den Antwortzeiten bei meinen Tests keinen signifikanten Unterschied gemerkt.
Und wenn, dann spielte sich das im 1/100 oder 1/10 Sekundenbereich ab.
--> Für mich war klar:
UDP ist zwar "schneller" als TCP - das ist für ganz viele das alles entscheidende Argument: Möglichst kurze Antwortzeiten (immer Rekorde brechen) - dem kann ich mich aber nicht anschließen !
TCP war immer noch rasent schnell und zudem eben auch "sicherer" - und das ist für mich das entscheidende Argument: Gute Antwortzeiten bei guter Sicherheit
Denn was bringen mir UDP-Bestzeiten, wenn es dann immer wieder zu Rucklern kommt, weil eben ab und zu die eine oder andere UPD-Anfrage eben NICHT am Ziel ankommt.
Ich könnte mir vorstellen, dass dies Erkenntnis vielleicht auch vielen anderen helfen könnte.
Und zwar den "WLAN" und "DLAN" geplagten Usern.
Auch hier kann ich es mir geradezu bildlich vorstellen, wie immer mal wieder, die eine oder andere "Fire-And-Forget"-Anfrage NICHT ankommt und es zu Freezer kommt.
Wenn aber immer nachgefragt wird, ob die Anfrage auch wirklich angekommen ist .....
==> Das ist wie gesagt momentan meine VERMUTUNG !!!
==> Hier habe ich keinerlei Erfahrungen gesammelt.
==> Aber vielleicht zeigen es ja die Rückmeldungen, ob ich mit dieser Vermutung richtig lag.
In diesem Sinne:
Viel Spaß beim Testen !
Zuletzt bearbeitet:
