ESP Arduino TCP Sensordaten

[Marc (Gast)]

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.

  // Send the response to the client
  client.print(s);
  //delay(100);
  Serial.println("Client disonnected");

Wäre es nicht schneller, die Verbindung zu belassen?

[Michael U. (amiga)]

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

[Stefan F. (Gast)]

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.

[Marc (Gast)]

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

[Stefan F. (Gast)]

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)?

[Marc (Gast)]

>HTTP/1.1

Eigentlich brauche ich gar kein HTTP. Ich kann TCP auch so verwenden.
Ich werde eine Python-Script als Kommunikationspartner auf dem PC 
nehmen, dann kann man die Datenaufnahme via PingPong triggern.

Hier gibt es eine gute Beschreibung zu Python und TCP:
https://docs.python.org/3/howto/sockets.html

[Torsten (Gast)]

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/

[semonbright (Gast)]

try this simple python socket program..

http://net-informations.com/python/net/socket.htm