WebSocket via DevIO?

rudolfkoenig · 24 Juni 2020, 09:46:12

HttpUtils_NonblockingGet erzeugt keinen weiteren Prozess, sondern traegt sich in die globale select Liste ein, sowohl fuers Schreiben, wie auch fuers Lesen. Bei gesetzten dnsServer wird auch die DNS-Aufloesung per eigene Routine (wieder ueber den globalen select) nicht blockierend abgewickelt. D.h. es wird nirgendwo gewartet/geschlafen, und der Ressourcenverbrauch ist minimal.

Kein Regel ohne Ausnahme: Zertifikataustausch/Cryptoverfahren Aushandlung am Anfang einer TLS/HTTPS Verbindung.
Aber da gibt es auch ein Timeout, insofern ist es nicht sehr tragisch.

dominik · 19 Juli 2020, 22:04:59

Ich habe gerade festgestellt, dass bei Websockets
SimpleRead und SimpleReadWithTimeout
unterschiedliche Ergebnisse liefern.

Ich denke es muss noch ein

Code Auswählen

DevIo_DecodeWS($hash, $buf) if($hash->{WEBSOCKET})
hier mit rein:
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/DevIo.pm#L99

Einen Nachteil hat die WithTimeout Funktion noch, es wird nie ein disconnect erkannt, wobei ich da jetzt keine Idee hätte wie man das korrigiert.

//EDIT..damit funktionierts:

Code Auswählen

sub
DevIo_SimpleReadWithTimeout($$)
{
  my ($hash, $timeout) = @_;

  my $rin = "";
  vec($rin, $hash->{FD}, 1) = 1;
  my $nfound = select($rin, undef, undef, $timeout);
  if ($nfound > 0) {
    my $buf = DevIo_DoSimpleRead($hash);
    $buf = DevIo_DecodeWS($hash, $buf) if($hash->{WEBSOCKET});
    return $buf;
  }
  return undef;
}

rudolfkoenig · 20 Juli 2020, 15:31:04

Ich will eine "nicht erwuenschte" Funktion wie DevIo_TimeoutRead (steht im Kommentar drueber: DO NOT USE IT!) nicht erweitern.
Lieber wuerde ich sie entfernen, leider gibt es noch ein paar Module, die sie verwenden.

KölnSolar · 20 Juli 2020, 18:35:59

ZitatLieber wuerde ich sie entfernen, leider gibt es noch ein paar Module, die sie verwenden.

Ein erster Schritt wäre vielleicht die Beschreibung aus dem Wiki zu entfernen. $:-\$

Grüße Markus

dominik · 20 Juli 2020, 18:42:08

Ok, wenn die Funktion nicht weiter verwendet werden soll, ist das natuerlich ein Argument.

krikan · 20 Juli 2020, 18:53:14

Zitat von: KölnSolar am 20 Juli 2020, 18:35:59
Ein erster Schritt wäre vielleicht die Beschreibung aus dem Wiki zu entfernen. $:-\$

Meiner Meinung nach ergab sich "nihct nutzen" schon aus dem Wiki und der jeweils vorhandenen Warnung; habe jetzt noch jeweils "NICHT NUTZEN" in der Warnungs-Box ergänzt. "Entfernen" gefiel mir nicht. Wer es anders möchte, kann gerne zur Tat schreiten.

Gruß, Christian

dominik · 18 August 2020, 18:19:46

Hi,

ich nutze die DevIO Websockets um eine Schnittstelle für Python zu bauen. Nun habe ich nach langer Fehlersuche festgestellt, dass DevIo_DecodeWS scheinbar nicht immer richtig funktioniert. Den genauen Fehler konnte ich noch nicht finden, hier jedoch die Beschreibung:
- Es kommt manchmal vor, dass Websocket Msgs nicht verarbeitet werden. Das bedeutet, aus DevIo_DecodeWS kommt "" zurück obwohl eine Nachricht vorliegt.
- Erst wenn ich die nächsten Msgs empfange, erhalte ich dann die vorige Msg. Ich habe das Gefühl, dass die Nachricht in .WSBUF drin ist, jedoch noch nicht als final angesehen wird.
- Dieses Verhalten konnte ich vor allem feststellen, wenn sehr viele Msgs gesendet und empfangen werden.

Ich habe daher mal in meinem Code DevIo_DecodeWS deaktiviert und statt dessen die Websocket Frames direkt mit Protocol::Websocket::Frame (https://metacpan.org/pod/Protocol::WebSocket::Frame) dekodiert. Damit kommen die Nachrichten sofort an.
Leider kann ich im Moment noch keine bessere Fehlerbeschreibung liefern, wenn ich den Fehler besser eingrenzen kann, schreibe ich nochmals.

rudolfkoenig · 19 August 2020, 09:58:05

Danke fuer die Meldung.
Ich habe den Code auf diese Symptome hin untersucht, und einen "passenden" Bug behoben.

Falls es nicht helfen sollte, dann brauche ich den Inhalt von .WSBUF, oder (idealerweise) eine Anleitung zum Nachstellen.

dominik · 19 August 2020, 22:29:51

Zitat von: rudolfkoenig am 19 August 2020, 09:58:05
Danke fuer die Meldung.
Ich habe den Code auf diese Symptome hin untersucht, und einen "passenden" Bug behoben.

Falls es nicht helfen sollte, dann brauche ich den Inhalt von .WSBUF, oder (idealerweise) eine Anleitung zum Nachstellen.

Super, danke dir!
Ich werde deinen Fix morgen testen und gebe dir dann bescheid.

//Edit: Achja, bei Websocket::Protocol::Frame kann man bei mehreren Nachrichten im selben Frame mit ->next jeweils den die naechste Msg extrahieren. Ich denke das wird mit DecodeWS aktuell noch nicht gehen, oder? Sonst muesste man ja ein Array an Nachrichten aus DecodeWS zurueck schicken.

dominik · 20 August 2020, 20:34:11

Hi,

der Fix macht es besser, aber leider noch nicht 100% perfekt. Manche Msgs kommen gar nicht an. Ich glaube das liegt daran, dass zwar der gesamte Frame gelesen wird, aber nur die erste Msg darin verarbeitet wird.

Ich denke man muss wirklich ein Array an Msgs zurueck liefern, anders wird es vermutlich nicht gehen. Oder man baut auch eine ->next Function wo man dann zur naechsten empfangenen Msg iterieren kann.

rudolfkoenig · 20 August 2020, 20:47:55

Der Fix liefert alle Daten "zusammengeklebt" als ein String zurueck, ohne den Fix wurde nur das erste Paket zurueckgeliefert. Welche Anwendung schickt mehrere einzelne Pakete, ohne auf eine Antwort zu warten?

Um weiter zu suchen brauche ich was zum Nachstellen.

dominik · 20 August 2020, 20:55:38

Ah, verstanden.

Ich baue gerade an einem FHEM Python Binding und da kann es durchaus vorkommen, dass z.B. mehrere readingsSingleUpdate an FHEM geschickt werden und die Antworten dazu in Python wieder ausgewertet werden. Es kann also sein, dass 10 readingsSingleUpdate an FHEM gehen und auf Python Seite wird dann asynchron auf die jeweiligen Antworten gewartet.

Nachdem ich keinen Separator in den Nachrichten verwende, mach ich auf FHEM Seite auch kein split(), sondern empfange einfach eine Nachricht nach der anderen und verarbeite diese.

rudolfkoenig · 20 August 2020, 21:01:36

Ich fuerchte die aktuelle Implementierung garantiert es nicht, dass die Pakete auch einzeln ausgeliefert werden: ich empfehle einen Trenner einzubauen.

dominik · 20 August 2020, 21:05:08

Ok, dann werde ich mir das anschauen, eigentlich wollte ich das eher vermeiden. Da es JSON Pakete sind, muesste ich das mit einem entsprechender Parser machen koennen.

Danke dir!

dominik · 24 November 2020, 22:03:30

Hi,
noch eine Anfrage zum Websockets DevIO Device.

Architektur:
- BindingsIO Modul welches DevIO nutzt
- PythonModule welches BindingsIO als IO Device nutzt
- Python Server welcher auf DevIO Websocket Connections reagiert

Es gibt mehrere PythonModule Devices aber nur ein BindingsIO Device welches als DevIO benutzt wird. Nun kommt es manchmal vor, dass nach einem Neustart von Python Server nicht eine Verbindung zum Python Server via BindingsIO aufgebaut wird, sondern gleich mehrere. Jedoch funktionieren diese dann nicht. Nach einem nochmaligen Neustart vom Python Server wird dann meistens nur eine Verbindung aufgebaut und dann klappt auch alles.

Habt ihr eine Idee wo es im DevIO Device vielleicht vorkommen kann, dass gleichzeitig mehrere Connections aufgebaut werden? Ich dachte da an ReadyFn, das ja meines Wissens öfter aufgerufen wird. Ich mach in ReadyFn folgendes
https://github.com/dominikkarall/fhem_pythonbinding/blob/master/FHEM/10_BindingsIo.pm#L162
Wird eventuell der Callback nicht abgewartet bevor nochmals per DevIo_OpenDev versucht wird das Device zu verbinden?