gelöst cccam oder cs378x?

[Puddies]

Welches Protokoll ist für das Sharing von einem Gerät zu einem weiteren Gerät zwischen 2 verschiedenen Haushalten eher zu empfehlen? cccam oder cs378x oder noch ein ganz anderes?

Falls das hierfür relevant sein sollte, meine Situation ist folgende:

Server:
vu+ duo4k, per LAN verbunden, Haushalt A.

Client:
vu+ uno4kse, per dLAN verbunden, Haushalt B, Zugriff auf Haushalt A über myfritz.net Adresse.

 

[sabotaGe84]

Ich mache es mit dem Cccam Protokoll und habe keine Probleme damit. Performance kannst du mit einem Wechsel des Protokoll's auch nicht rausholen.

 

[Pilot]

Hab die Erfahrung gemacht, das mit cs378 Protokoll besser die Verlängerungs Emms fließen für meine Abo Karten

 

[barci]

Definitiv cs378x

 

[Osprey]

@Puddies
welche lokale Karte wird geshart?
CCcam ab 2.2.1 hätte den Vorteil von good und bad sids Erkennung.

 

[pehedima]

Für reine Home-Home Anwendungen würde ich immer cs378x nehmen. Bei anderen Anwendungen sollte das von Fall zu Fall entschieden werden.
Das cs378x Protokoll ist längst nicht so überladen wie cccam und hat somit schon eine bessere Performance.

Bei cccam kommt nämlich noch diese oben erwähnte good/bad sid Auswertung, die Weitergabe aller Kartendaten des entsprechenden Readers, die HOP-Auswertung usw. hinzu.
Wer das alles nicht braucht fährt mit cs378x m.E. besser.

 

[Puddies]

@Osprey
Es handelt sich um eine V13 in der vuduo4k. Es ist nur diese eine Karte, die auch wiederum nur auf ein weiteres Gerät geshared wird.
D.h., dann würde ich am besten auf cs378x umstellen.

 

[elogugu]

Bei mir läuft im Netzwerk alles mit cs357x (IPC)

 

[pehedima]

cs357x sollte wirklich nur im lokalen Netzwerk genutzt werden.
Da das Protokoll auf UDP basiert und somit nach dem Slogan 'nach mir die Sintflut' arbeitet kann das schon zu Aussetzer führen.

Ein TCP basierendes Protokoll (wie cs378x, cccam) ist gerade beim Verlassen der eigenen vier Wände einem UDP Protokoll vorzuziehen.
D.h. nicht, dass UDP dafür komplett ungeeignet ist aber man muss schon mit mehr Problemen rechnen.

 

[tem_invictus]

Wieso Slogan "nach mir die Sinnflut" ?
Bei UDP wird halt einfach keine Verbindung zwischen Sender und Empfänger aufgebaut, bevor Daten geschickt werden. Man kann also nicht nachvollziehen,
dass das Paket wirklich angekommen ist. Was man bei TCP kann, allerdings ist TCP dadurch langsamer und "aufgeblasener".
Bei dieser Anwendung sehe ich da auch keine Sicherheitsbedenken für außerhalb der eigenen vier Wänden.

Ich nutze bei einigen Clients cs357x als Failover Reader, wenn die cs378x Verbindung aus irgend einem Grund nicht schnell genug war.

Übrigens setzt HTTP/3 auch auf UDP auf, weil es einige Vorteile bringt.

 

[pehedima]

Wieso Slogan "nach mir die Sinnflut" ?

Die Erklärung hast du dir schon selbst gegeben

Bei dieser Anwendung sehe ich da auch keine Sicherheitsbedenken für außerhalb der eigenen vier Wänden.

Es geht ja auch nicht um Sicherheit.

 

[crash7782]

Wie kann ich denn Failover einrichten?

 

[ghost0815]

Es ist wohl Fallback gemeint......

Sie müssen registriert sein, um Links zu sehen.

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

Ich habe etwas mit WLAN Bridges und dLAN (inkl. Kaskaden aus beidem) in Verbindung mit einem OScam Client experimentiert. Wie zu erwarten war kam es recht häufig zu Freezern, teilweise sogar auf der HD01 die ja bekanntermaßen recht viel verzeiht. Die NDS V14 freezt naturgemäß noch...

www.digital-eliteboard.com

 

[Kind regards]

Da das Protokoll auf UDP basiert und somit nach dem Slogan 'nach mir die Sintflut' arbeitet kann das schon zu Aussetzer führen.

was aber nichts mit den Protokoll zu tun hat sondern einfach mit einer schlechten Verbindung (dlan etc.) , habe hier mit cs357x auch kein Problem
deshalb jeder wie er mag, deshalb sind die Module ja vorhanden und somit kann jeder für sich testen , was bei ihm am besten funktioniert

 

[pehedima]

was aber nichts mit den Protokoll zu tun hat

Das hat in sofern mit dem Protokoll zu tun, da es kein Handshake nutzt. Kommt eine Nachricht beim Ziel nicht an dann ist das halt so und die Information ist verloren (Freezer)
Bei TCP-Verbindungen wird der Sender nochmal aufgefordert die Nachricht erneut zu senden. Kommt sie dann an entstehen halt keine Freezer.

Das eine Nachricht nicht ankommt, kann sehr unterscheidliche Ursachen haben. Auf einige hat man selbst keinen Einfluss.
Daher bei Freezer mit UDP-Protokollen einfach mal ein TCP-Protokoll nutzen.

Wie bereits oben erwähnt, kann natürlich UDP (cs357x) ebenfalls bei I-Net Verbindungen eingesetzt werden, bei einigen läuft das nicht einmal im lokalen Netz.
Einfach mal testen.