Hallo, ich betreibe zwei ESP8266 als WiFiServer und WiFiClient. Normalerweise funktioniert alles wie es soll. Es taucht allerdings ein Problem auf, wenn der Client sich nicht "normal" abmeldet, sondern z.B. einfach die Stromversorgung abgeschaltet wird und er so auf dem Netzwerk fällt. In diesem Fall erkennt der Server nicht, dass die Verbindung nicht mehr zum Client besteht. Er bleibt deswegen für einen neuen Clients gesperrt bis nach ca. 15 bis 20 Minuten wohl eine anderer Mechanismus die Verbindung beendet. Meine Anwendung benötigt, dass der Client sich normalerweise nicht disconnected , sondern solange mit dem Server verbunden bleibt und von diesem mit Daten versorgt wird bis der Client sich "normal" abmeldet. Ich benutze client.flush und client.disconnected() beim Server, das scheint aber für diesen Fall nicht auszureichen. Meine umfangreichen Recherchen im WEB habe eigentlich keine Lösung des Problems gefunden. Kann mir hier bitte jemand weiterhelfen? Danke
:
Bearbeitet durch User
Üblicherweise kann man einstellen, wie lange ein Server eine Client-Verbindung aufrechterhält auch ohne dass dieser etwas schickt (timeout) - den kürzer setzen und dann ggfs keepalive einbauen.
Jan schrieb: > Üblicherweise kann man einstellen, wie lange ein Server eine > Client-Verbindung aufrechterhält auch ohne dass dieser etwas schickt > (timeout) - den kürzer setzen und dann ggfs keepalive einbauen. Wie macht man das bitte ?
Sende periodisch (z.B. alle 15s) Pakete, und wenn Du auf drei oder 4 keine Antwort bekommen hast, dann ist die Gegenstelle weg. Pakete können entweder ICMP/Echo request/response (ping) sein, oder irgendwelche Anfragen im verwendeten Kommunikationsprotokoll. fchk
Ich kenne die Server-Seite von ESP8266 APIs nicht. Nebenbei, du verrätst uns nicht mal welche Umgebung (API, Sprache, Toolkits, ...) geschweige denn welche Protokolle oberhalb Layer 2 du verwendest. Aus "WiFi" kann man erraten was L1 (Phys) und L2 (MAC) sind, aber der Rest fehlt. Daher nur ein paar generelle Hinweise. Normalerweise baut man einen Server "concurrent" auf. D.h. der Server kann mehrere Verbindungen zu Clients gleichzeitig abhandeln. Dabei fällt ein hängender Client nicht so ins Gewicht und kann irgendwann von irgend einem Timeout abgeräumt werden. Nur bei ganz einfachen Diensten und wenn es eben nicht auf allzeitige Verfügbarkeit des Servers ankommt baut man einen iterativen Server. Aber genau das scheinst du gemacht zu haben. D.h. an dem Punkt würde ich mal die gesamte Architektur überdenken und tief in das verwendete API und die angebotenen Mechanismen des Systems schauen um einen concurrent Server zu bauen. Die bereits erwähnten Timeouts musst du sowieso haben, egal ob iterativ oder concurrent. Bei concurrent hast du nur mehr Luft und kannst dem Client mehr Zeit für z.B. Wiederholungen geben wenn die Verbindung gestört ist.
Hannes J. schrieb: > Aus "WiFi" kann > man erraten was L1 (Phys) und L2 (MAC) sind, aber der Rest fehlt. Ich habe kein Problem damit zuzugeben, dass ich speziell davon keine Ahnung habe. Ich verwende die landläufigen Libraries in diesem Fall für den ESP8266 in C und benutze Platformio. Ich bitte also um Nachsicht bei meiner Frage. Die Librarybeschreibungen die ich dazu gefunden haben sagen für mich nichts darüber aus, was hinter den Funktionen im Detail steckt und wie man eventuelle Probleme der beschriebenen Art verhindert oder umgeht. Oder wie und wo man Timeouts anwendet oder benutzt. Meine Anwendung basiert auf allseits verfügbare WiFi Server/Client Examples aus dem WEB.
:
Bearbeitet durch User
Bot N. schrieb: > Die Librarybeschreibungen die ich dazu gefunden haben sagen für mich > nichts darüber aus, was hinter den Funktionen im Detail steckt und wie > man eventuelle Probleme der beschriebenen Art verhindert oder umgeht. > Oder wie und wo man Timeouts anwendet oder benutzt. > Meine Anwendung basiert auf allseits verfügbare WiFi Server/Client > Examples aus dem WEB. Wenn man wüsste, welche Library du verwendest (Link?!), gäbe es vielcht jemand, der die kennt oder sachkundiger als du bist.
Wenn's was hilft, hier was zu den Includes die mit WiFi zu tun haben. https://docs.arduino.cc/libraries/wifi/ https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/readme.html https://docs.arduino.cc/language-reference/en/functions/wifi/client/ https://docs.arduino.cc/language-reference/en/functions/wifi/server/ Alles so wie aus vielen Beispielen zu diesem Thema im WEB zu finden.
:
Bearbeitet durch User
Die Doku von Arduino.cc kannst du schon mal knicken, weil Arduino nichts mit dem ESP8266 am Hut hat. Der Arduino Core für den ESP8266 basiert auf auf den NONOS SDK von Espressif und stammt weder von Espressif noch von Arduino. Die Autoren haben sich bemüht, das Verhalten der originalen Arduino Variante so weit es geht nachzuahmen. Das SDK von Espressif verwendet wiederum lwIP. Relevant ist also nur das bisschen Doku auf https://arduino-esp8266.readthedocs.io und https://github.com/espressif/ESP8266_NONOS_SDK und https://savannah.nongnu.org/projects/lwip/ Oder besser: Quelltexte untersuchen. Frank K. schrieb: > Sende periodisch (z.B. alle 15s) Pakete, und wenn Du auf drei oder 4 > keine Antwort bekommen hast, dann ist die Gegenstelle weg. So würde ich es auch empfehlen. Da die Gegenseite ihr Verschwinden nicht signalisiert, bleibt die Verbindung für immer bestehen. Es sei denn, deine Software auf dem ESP8266 trennt sie aktiv.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.