udp multicast support in fhem

[erwin]

ich baue noch so etwas wie TcpServer_MCastSend ein...

Sehr gut,
falls es was zu testen gibt, bitte darum!

[justme1968]

wenn du magst probier mal die angehängte version.

TcpServer_MCastSend($hash,$data) sendet an den port aus dem TcpServer_Open und die adresse aus TcpServer_MCastAdd.

optional kannst du auch noch nach $data aber auch adresse (und port) noch mit angeben.

[erwin]

ja, die Version ist ok!
l.g. erwin

[justme1968]

@erwin: ich habe analog zum TcpServer_MCastSend auch noch ein TcpServer_MCastRecv eingebaut das peer host und peer port auch für ipv6 ermittelt und zurück liefert.

@rudi: ich habe die aktuelle version des patch ganz oben (https://forum.fhem.de/index.php/topic,126290.msg1209591.html#msg1209591) angehängt und dort die doku komplettiert. da es bisher keine explizite doku für die TcpServerUtils könnte man den teil auch ins wiki stecken. oder fällt dir etwas besseres ein?

[erwin]

@Andre,

Die _MCastRecv($$$;$) funktioniert so nicht:
1) es fehlt:

Code Auswählen Erweitern

my $name = $hash->{NAME};
  my $sock = $hash->{SERVERSOCKET};
2) es werden die rx-daten nicht returned!

Mir ist nicht klar, wozu du in der routine peerhost,peerport brauchst....
l.g. erwin

[justme1968]

danke. keine ahnung was da beim diff schief gegangen ist. hab es oben repariert.

es kommt auf das protokoll und die anwendung an ob man peer host und port braucht.

beim plex modul senden alle player ihre aktuelle abspielposition per multicast ins netz und nur am peer host kann man feststellen um welchen player es sich handelt da der absender nicht teil der eigentlichen nachricht ist, bei mdns kann man z.b. am absenden port der gegenseite feststellen ob es eine voll umfänglich implementierung ist (5353) oder eine abgespeckte (alle anderen ports) da im rfc festlegt ist das nur eine komplette implementierung 5353 auch als sende port verwenden darf.

[erwin]

Ok, so funktionierts, ich war nur etwas verwirrt, weil ich (ohne nachzudenken...) erwartet hatte, dass die rx-daten returniert würden.
Danke für die Erklärung, das macht dann Sinn. Ich muss überlegen, ob ich den peerhost evtl. auch auswerten soll....
Danke Erwin

[rudolfkoenig]

@rudi: ich habe die aktuelle version des patch ganz oben (https://forum.fhem.de/index.php/topic,126290.msg1209591.html#msg1209591) angehängt und dort die doku komplettiert.

Ich habe den Patch mit leichten Aenderungen uebernommen:
- TcpServerUtils_Initialize entfernt
- die %opts Initialisierung angepasst, damit es fuer die bisherigen Protokolle garantiert nichts geaendert wird. Ich habe angenommen, dass fuer $multicast kein Unterschied zwischen undef und 0 gibt.
- Zeilen auf 80 Spalten umformatiert. Etwas irritierend ist die im Kommentar 4-mal gestellte gleiche Frage.

da es bisher keine explizite doku für die TcpServerUtils könnte man den teil auch ins wiki stecken. oder fällt dir etwas besseres ein?

Ich habe die obern erwaehnte Doku mit einem Hinweis auf dem Forumsartikel am Ende des Moduls zwischen =pod und =cut eingefuegt.
Wird entfernt, falls wir was Besseres gefunden haben.

[CoolTux]

Könnt Ihr Euch bitte einmal diesen Post anschauen.

https://forum.fhem.de/index.php/topic,126818.msg1214020.html#msg1214020

[rudolfkoenig]

Bessere Logs gibts hier: https://forum.fhem.de/index.php/topic,126789
Kurz: mit dem perl, was debian wheezy ausliefert, kann man TcpServerUtils.pm nicht laden.

Wheezy ist aus 2013, letzter Update aus 2016.
Perl 5.16 (aus 2012) enthaelt etliche der benoetigten Konstanten aus Socket.pm nicht, 5.18 (aus 2013) hat sie aber, soweit ich es beurteilen kann.
Da ist die Diskussion wieder: welche perl-Version ist eine Voraussetzung fuer "core FHEM".

Das Problem kann man vertagen, wenn man die Multicast-Routinen in eine separate Datei auslagert.
Vorteile:
- fachkundiger Maintainer
- Multicast brauchen die meisten Benutzer nicht.
- das "wheezy" Problem ist geloest.

Meinungen?

[Beta-User]

Meinungen?

Vielleicht unpopulär, aber m.E. sollten wir es mit dem support für "uralt-OS-Installationen" nicht übertreiben. Wer unbedingt (!) FHEM up-to-date halten will _und_ ein Uralt-OS behalten, muss halt perlbrew&Co bemühen. (Was aber möglicherweise dann wieder nicht gegen uralt-SSL-Versionen usw. hilft...)

Schon alleine, um "update-Muffel" etwas zu animieren, mit einer gewissen (2-3-jährlichen...!) Regelmäßigkeit mal die erforderlichen Wartungsarbeiten anzugehen. Die nächste Meldung, die von solchen Kandidaten dann nämlich kommt, ist "SD-Karte ist abgekachelt..."

(Das bedeutet nicht, dass man nicht die Option nutzen könnte, die Routinen in libraries auszulagern)

[justme1968]

wer auf der alten os version bleiben möchte soll auch auf der alten fhem version bleiben.

laut statistics betrifft es scheinbar sehr wenige anwender. und ich würde sagen es sind jetzt schon weniger als multicast nutzer. und bei letzterem kommen ganz sicher noch welche dazu.

ich würde die routinen eigentlich gerne zusammen lassen. auch wenn die überlappung klein ist funktionieren sie ja nur miteinander und verwenden die gleichen internals.

wie wäre es das Initialize wieder zu aktivieren, per eval zu prüfen ob multicast vorhanden ist und nur dann auch anzubieten? in verbindung mit einer möglichkeit das aus dem eigenen code auch abzufragen könnte man das dann später auch auf andere features ausdehnen. z.b. json und xml.

ssl wird ja auch per eval getestet und hat im prinzip das gleiche problem.

[CoolTux]

Ich bin Andres Meinung. Ich finde die Leute sollten anfangen ihre Systeme zu erneuern. Mittlerweile bin ich auch so das ich die Leute "zwinge" auf wenigstens Perl 5.18 zu gehen. Besser wäre 5.28.

Wir sollten empfehlen die TcpServerUtils.pm vom update aus zu schließen wenn sie auf ihrem alten System bleiben wollen.

[Beta-User]

Wenn, dann sollte man ein 6.1-legacy-deb mit unmittelbarem Stand vor dem update der TcpServerUtils.pm fertig machen, das dann _keine_ update.pm enthalten sollte ...

Kern-Module nur teilweise zu aktualisieren, funktioniert erfahrungsgemäß eine Zeitlang, bis es knallt. Wer so eine Murmel meint fahren zu müssen, dem sollte man nicht versuchen zu vermitteln, dass das eine Dauer-Lösung wäre, die mit minimalst-invasiven Mitteln langfristig funktioniert.

Just my2ct.

[rudolfkoenig]

wie wäre es das Initialize wieder zu aktivieren, per eval zu prüfen ob multicast vorhanden ist und nur dann auch anzubieten?

Ich wuerde mich freuen, wenn wir eine optionale Version hinkriegen wuerden.
Ich kann auch anbieten, das selbst zu machen, brauche aber dafuer einen Testfall.