Details über Broadcast Socket

[manül]

Hallo,

 

ich versuche derzeit den fehlenden Support für den Broadcast Socket im XBMC PVR Plugin umzusetzen. Portisch hat hier schon etwas Vorarbeit geleistet. Technisch gefällt mir aber die Methode über den UDP Broadcast nicht wirklich und das hat mehrere Gründe:

• Pro Computer/Device kann maximal ein Programm auf den Port horchen. Beschränkt durch den nötigen bind-call.
• Eventuelle Firewalls merkt man nicht. Ein fallback auf polling ist daher immer nötig.
• Klappt generell nicht wenn sich das Recording Service in einem "entfernten" Netz befindet.

Ich möchte daher anregen den Broadcast Port auf TCP umzustellen bzw. als Alternative anzubieten. Obige Punkte wären gelöst. Eine störende Firewall bekommt man bereits beim connect mit. Durch das implizite Keepalive wird die Verbindung von selbst aufrecht gehalten. Und Polling ist nicht mehr notwendig. Einzig um Verbindungsabbrüche/reconnect muss man sich als Client selbst kümmern.

Die Implementierung im Service ist leider etwas aufwendiger als derzeit - aber auch nicht wild. Technisch ist das sogar über das bestehende HTTP-Interface möglich, sofern der Webserver-Code da mitspielt (zB http://www.w3.org/TR/eventsource/).

 

Aber abgesehen von meinem Wunsch, kennt jemand alle Events/Strings die auftreten können? Mir sind derzeit nur "DVBVUPDATE TMR" und "DVBVUPDATE REC" bekannt.

Edited October 2, 2013 by manül

[Griga]

Ich habe Portisch, der im Moment zeitlich stark eingeschränkt ist, per PM auf diesen Beitrag hingewiesen.

 

Da Lars uns leider unerwartet verlassen hat, gibt es außer Portisch zur Zeit niemand, der nachvollziehen kann, was du genau meinst.

[Portisch]

Wie Griga sagt bin ich privat sehr mit dem Hausbau eingespannt.

Mitlesen tu ich aber täglich Im Büro finden sich immer ein paar Minuten...

 

Aber für Programmieren/Debugen und testen bleibt derzeit gar keine Zeit.

 

Es laut meiner Info von Lars damals diese Broadcasts:

• DVBVUPDATE REC: kommt wenn eine neue Aufnahme gemacht wird und/oder beim Löschen einer Aufnahme

Daher ist kein Polling der Aufnahmen notwendig, da der Client informiert wird wenn sich am Server was an der Recording-Database ändert.

• DVBVUPDATE EPG: sollte am client aber nicht berücksichtigt werden

Habe aber selber nicht ausprobiert warum das nicht verwendet werden sollte

• DVBVUPDATE TMR: kommt beim Löschen/Erstellen eines Timers
• DVBVUPDATE PWR: kommt wenn der RS den Server in den Standby/Ruhezustand schicken will

Somit weiß der Client das der Server (bald) nicht mehr verfügbar ist.

 

 

Ob man das ganze auf TCP umstellen kann weiß ich nicht. Das betrifft dann nicht mehr nur den RS sondern auch den DVBViewer selber.

[manül]

Es laut meiner Info von Lars damals diese Broadcasts:

• DVBVUPDATE REC: kommt wenn eine neue Aufnahme gemacht wird und/oder beim Löschen einer Aufnahme

Daher ist kein Polling der Aufnahmen notwendig, da der Client informiert wird wenn sich am Server was an der Recording-Database ändert.

• DVBVUPDATE EPG: sollte am client aber nicht berücksichtigt werden

Habe aber selber nicht ausprobiert warum das nicht verwendet werden sollte

• DVBVUPDATE TMR: kommt beim Löschen/Erstellen eines Timers
• DVBVUPDATE PWR: kommt wenn der RS den Server in den Standby/Ruhezustand schicken will

Somit weiß der Client das der Server (bald) nicht mehr verfügbar ist.

 

Danke für die Liste. Wie gesagt, gefällt mir das ganze technisch derzeit gar nicht. Gründe hab ich ja genannt.

 

Unabhängig ob nun TCP oder UDP könnte man zudem noch mehr Information über das Update einbauen. Beispielsweise ob ein/e Timer/Aufnahme gelöscht/aktualisiert/erstellt wurde und dessen ID mit übertragen. Dann erspart man sich das erneute parsen aller Timer/Aufnahme und muss nicht selbst vergleichen, was sich geändert hat. Das ist insbesondere für kleine Devices wie dem Raspberry PI und für Leute mit ~5000 Recordings (*hint* ) interessant. Wenn man weiter bei UDP bleibt muss man aber aufpassen dass die Paketgröße nicht die MTU überschreitet.

[Portisch]

Geht das verändern einzelner Recording Einträge bei XBMC überhaupt?

Soweit ich mich erinnern kann muss man immer die komplette Liste von Addon an XBMC übergeben, da bei dem Pushpack XBMC die Liste komplett leert.

[manül]

Geht das verändern einzelner Recording Einträge bei XBMC überhaupt?

Soweit ich mich erinnern kann muss man immer die komplette Liste von Addon an XBMC übergeben, da bei dem Pushpack XBMC die Liste komplett leert.

Komplett leeren tut XBMC nur bei bzw. vorm GetRecordings(..). Man kann aber trotzdem jederzeit neue Recordings über PVR->TransferRecordingEntry(..) eintragen oder aktualisieren. Identifier ist hier die recording ID. https://github.com/xbmc/xbmc/blob/master/xbmc/pvr/recordings/PVRRecordings.cpp#L480 wird hier aufgerufen (über ein paar Umwege).

Löschen geht aktuell aber nur über ein komplettes Update. Selbiges gilt für Timer.

[nuts]

Danke für die Liste. Wie gesagt, gefällt mir das ganze technisch derzeit gar nicht. Gründe hab ich ja genannt.

 

Die Punkte sind, zumindest mir, technisch nicht so 100% klar.

 

1.) Nicht ganz klar wieso das ein Problem ist.

2.) Könnte man das nicht anders lösen? z.B. wenn man Events triggern könnte?

3.) Mit einem "entfernten" Netz meinst du außerhalb des subnets in dem der RS läuft? Falls ja: Wieso ist das wichtig?

Edited October 3, 2013 by nuts

[manül]

1.) Nicht ganz klar wieso das ein Problem ist.

Beispielweise weil User gerade beim Einrichten der Software DVBViewer Client + XBMC nebeneinander laufen lassen. Oder wenn Benutzer die Software wechseln, aber zuerst XBMC starten und dann erst DVBViewer Client beenden. Die Beispiele klingen zugegebenermassen etwas konstruiert, aber es ist einfach ein hässlicher Nebeneffekt durch den Broadcast Socket.

 

2.) Könnte man das nicht anders lösen? z.B. wenn man Events triggern könnte?

Könnte man. Allerdings hat UDP keine Garantie auf Empfang - auch wenns hier nur das lokale Netz ist. Ein weiteres, vermutlich deutlich größeres Problem: Damit das Recording Service über die Broadcast Adresse empfangen kann, muss es ebenfalls auf den Port horchen/binden. Dann kann das aber kein lokaler Client mehr. Mit TCP geht das out of the box.

 

3.) Mit einem "entfernten" Netz meinst du außerhalb des subnets in dem der RS läuft? Falls ja: Wieso ist das wichtig?

Ja, meine ich. Einige Benutzer haben solche Strukturen - warum auch immer. Letztens hat einer über Proxy aufs Recording Service zugegriffen.

 

Durch die ganzen Nachteile überlege ich derzeit ernsthaft ob es die Mühe wert ist. Weil den polling Code muss man derzeit so und so behalten, auch wenn er inaktiv gesetzt werden kann, sobald ein Event empfangen wurde.

Edited October 3, 2013 by manül

[nuts]

1.) Ist das echt so? Muss ich morgen mal nachstellen.

 

2.) Dachte man triggert eine Broadcast Nachricht z.B. per webapi um zu prüfen ob man aufs polling verzichten kann.

Könnte auch für sonstige Anwendungen, die mit dem RS Daten tauschen sinnvoll sein.

Allgemein kann man die Events in Zukunft ja noch ausbauen.

 

3.) Für die Exoten Setups könnte das ja drin bleiben.

Also ich bin grundsätzlich kein Fan von polling.

Edited October 9, 2013 by nuts

[manül]

1.) Ist das echt so? Muss ich morgen mal nachstellen.

Ja, ist so. Hier ein zusammen kopiertes Beispiel mit dem ich getestet habe: http://pastie.org/8375948

 

2.) Dachte man triggert eine Broadcast Nachricht z.B. per webapi um zu prüfen ob man aufs polling verzichten kann.

Könnte auch für sonstige Anwendungen, die mit dem RS Daten täuschen sinnvoll sein.

Allgemein kann man die Events in Zukunft ja noch ausbauen.

Ja, gut. Das könnte man vmtl. relativ einfach ins RS einbauen. Seh ich aber auch als hässlichen Umweg.

 

3.) Für die Exoten Setups könnte das ja drin bleiben.

Also ich bin grundsätzlich kein Fan von polling.

Ich auch nicht, aber darum geht es. Wenn die Events über TCP kommen (bzw. als web events) kann man den polling code gesamt entfernen. Mir ist natürlich klar dass das nicht von heute auf morgen umgesetzt sein wird. Deswegen wars auch ein Vorschlag.