ESP Arduino TCP Sensordaten

Marc Gast #5629875
Lesenswert?
• ▲
▼ 
Es sollen Daten von einem Sensor via TCP zum PC übertragen werden.

Hier gibt es ein Beispiel für einen WiFiWebserver:
https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/examples/WiFiWebServer/WiFiWebServer.ino

Wenn ich es richtig verstehe, wird für jede TCP-Übertragung eine 
Verbindung aufgemacht und am Schluss etwas zum Client-PC zurück gesendet 
und danach die Verbindung unterbrochen.

1
  // Send the response to the client

2
  client.print(s);

3
  //delay(100);

4
  Serial.println("Client disonnected");


Wäre es nicht schneller, die Verbindung zu belassen?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Michael U. #5629919
Lesenswert?
• ▲
▼ 
Hallo,

das ist letztlich ein Webserver bei dem der Client (PC) die Daten 
anfordert.
Der Client entscheidet auch, ob die Verbindung nach bearbeiten der 
Anfrage geschlossen werden soll oder bestehen bleiben soll. 
Normalerweise wird geschlossen, was soll der Server mit der offen 
gehaltenen Verbindung, wenn sich der Client dann nie wieder meldet oder 
erstmal 100 andere Clients Anfragen schicken. Ein Webserver im Internet 
hätte ann nach 5 Minuten eine Liste der paar tausensend Anfragen und die 
entsprechende Anzahl offene verbindungen... Kostet Speicher, Rechenzeit 
(gibt es diese Verbindung schon in meinen Listen) usw.

Auf einem ESP wird man die TimeOuts vermutlich eher kürzer setzen. Wenn 
man nur einen Client zuläßt, weil die Resourcen nicht so üppig sind, 
käme ein andeer nei zum Zuge, weil ja noch eine Verbindung zu Client x 
seit yy Minuten besteht.

Gruß aus Berlin
Michael
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan F. Gast #5629930
Lesenswert?
• ▲
▼ 
Marc schrieb:
> Wäre es nicht schneller, die Verbindung zu belassen?

Ja.

Das ist der wesentliche Unterschied zwischen HTTP/1.0 und HTTP/1.1. Wenn 
du die Verbindung aber nicht schließt, musst du dem Client anders 
mitteilen, wann der Request komplett beantwortet ist. Dazu hast du 2 
Möglichkeiten:

a) Vor dem Antworten einen Content-Length Header senden.
b) Die Antwort in sogenannte Chunks zerstückeln. Das letzte Stück hat 
die Länge 0.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Marc Gast #5629957
Lesenswert?
• ▲
▼ 
>Normalerweise wird geschlossen, was soll der Server mit der offen
>gehaltenen Verbindung,

Ok.
Ich hatte mir folgendes Beispielszenario vorgestellt: Eine Art Oszi, bei 
der immer 1000 ADC-Werte in eine Buffer gelesen und dann übertragen 
werden, wenn eine TCP-Anfrage kommt.
Um da eine Echtzeitanzeige zu erreichen, hätte ich vermutet, dass die 
Verbindung offen bleiben kann.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan F. Gast #5629993
Lesenswert?
• ▲
▼ 
Echtzeit und "normales" Netzwerk sind zwei Welten, die sich nicht mögen. 
Echtzeit und WLAN mögen sich noch weniger.

Der Performancevorteil von HTTP/1.1 beruht im wesentlichen darauf, dass 
der Browser die nächsten Requests auf der bestehenden Verbindung schon 
los schicken kann, während er auf eine Antwort wartet. Also full-duplex.

HTTP/1.0 arbeitet hingegen im half-duplex Modus. Da wird streng 
abwechselnd gesendet und empfangen. Bei HTTP/1.0 wurden daher schon früh 
zwei Verbindungen gleichzeitig verwendet, später bis zu 8 (ist das noch 
aktuell)?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Torsten Gast #5655662
Lesenswert?
• ▲
▼ 
Vielleicht schaust du dir mal MQTT an. Ursprünglich wollte ich die Daten 
auch mal so übertragen, wie du das beschreibst, aber mittels MQTT ist 
das viel komfortabler.

Setup:
Du hast einen Broker (läuft z.B. als Daemon auf nem Raspi) und über 
diesen tauschen sich Clients über Topics aus. Ein Topic wäre z.B. 
"Wohnzimmer/Temperatur". Jeder Client kann zu einem Thema eine 
schreibende (publish) und eine lesende (subscribe) Haltung haben. Sobald 
ein Client in ein Topic was schreibt, verschickt der Broker Notifies an 
die anderen Clients. D.h. diese Clients kriegen die Änderung sofort mit. 
Es gibt sogar QoS-Regeln, damit man auch sicherstellen kann, dass der 
Empfänger die Nachricht erhält.
Lib: https://github.com/knolleary/pubsubclient/
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren