TcpServerUtils.pm

[justme1968]

ich bin gerade einem aktuellen problem im itunes modul auf der spur. und mir sind zwei dinge nicht klar. das modul erzeugt wenn es noch nicht mit dem itunes gegenstück gepaired ist einen temporären tcp sserver. dieser wird nur für diese eine pairing anfrage von itunes gebraucht.

- bis her habe ich direkt nach dem TcpServer_Accept den server mit TcpServer_Close wieder zu gemacht. das client socket ist dabei erhalten geblieben und hat die anfrage beantwortet. inzwischen scheint sich in fhem.pl etwas geändert zu haben und ich bekommen ein

2013.11.17 18:58:19 1: ERROR: Select error -1 (9), error count= 0
2013.11.17 18:58:19 1: Found and deleted bad fileno for i.0

. ist das so beabsichtigt?

- in TcpServer_Close wird das in TcpServer_Open erzeugte temporäre objekt zwar aus der select list entfernt aber nicht gelöscht. telnet scheint direkt ein CommandDelete aufzurufen und kein TcpServer_Close für den client. ist das so beabsichtigt ?

gruss
  andre

[ntruchsess]

ich habe das im FRM so gehandhabt, dass der ServerSocket offen bleibt, weil der Client ja reconnecten kann ohne dass die bisherige Verbindung (clientseitig) sauber geschlossen wird. Macht man den ServerSocket nach dem ersten Accept zu, dann kann es leicht passieren, dass der Client bis zum TCP-timeout (je nach OS ca. 10Minuten) nicht wieder verbinden kann, wenn er aus irgendeinem Grund abgeklemmt (oder hart neugestartet) wird.
Wenn ein neuer Client verbindet, dann baue ich eine schon bestehende Clientverbindung ab und arbeite auf der neuen weiter.

- Norbert

[rudolfkoenig]

Ich habe zwar am select was gedreht (Write und Except Pruefung eingebaut), das sollte aber mAn das bisherige Verhalten fuer Read nicht aendern.

Die FHEM-Meldung besagt, dass man in selectlist ein FD spezifiziert hat, was select mit 9 (Bad Filedescriptor) quittiert, d.h. etwas was nicht zum Lesen geoeffnet ist. Der Code macht eine extra Schleife, u festzustellen wer genau der Uebeltaeter ist.

Es ist nicht die Aufgabe von TcpServer_Close den hash zu entfernen, sondern nur die Verbindung zuzumachen. Und das macht sie mAn nach richtig. Da das FD aus selectlist entfernt wird, kann TcpServer_Close vor der vorherigen Meldung auch nicht aufgerufen worden sein.

[justme1968]

@norbert: das ist im prinzip richtig. beim pairing request aber nicht so kritisch. aber ich kann auch später zu machen. leider bekomme ich dann den gleichen fehler.

@rudi: ich versuche noch mal das ganze an einem abgespeckten beispiel zu reproduzieren.

was ich mache ist folgendes:

- TcpServerOpen
- TcpServerAccept
- TcpServerClose auf den server
- Daten senden zum client
- TcpServerClose auf den client

der fehler kommt nach dem TcpServerClose auf den server. das daten senden zum client geht danach einwandfrei und ich kann dann auch den client schliessen ohne fehler

gruss
  andre