Forum: Mikrocontroller und Digitale Elektronik ESP8266: wie ganz abgeschalteten Client erkennen?


von Bot N. (botnec)


Lesenswert?

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
von Jan (dunno)


Lesenswert?

Ü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.

von Bot N. (botnec)


Lesenswert?

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 ?

von Frank K. (fchk)


Lesenswert?

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

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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.

von Bot N. (botnec)


Lesenswert?

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
von Rahul D. (rahul)


Lesenswert?

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.

von Bot N. (botnec)


Lesenswert?


: Bearbeitet durch User
von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?

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
Noch kein Account? Hier anmelden.