Datenaustausch auf TCP/IP Ebene

ArduStemmi schrieb:
> Meine Bitte: Kann mir jemand erklären, wie der Datenstrom zwischen PC
> und ESP tatsächlich stattfindet?

Installier Dir doch auf dem PC einfach mal Wireshark und schau Dir die 
Datenpakete mal an.

Die vielen Ausrufezeichen verwirren mich.

Peter II schrieb:
> PittyJ schrieb:
>> Wenn es
>> WLan ist, dann gehen doch nur TCP oder UDP.
>
> nein, Wlan arbeiten auf MAC Ebene. Es geht es alles übertragen was
> gültige Ethernet Pakete sind.
das mag ja sein, aber wer sich so gut auskennt wie der TO wird wohl kaum 
ein eigenes Protokoll auf MAC Ebene aufsetzen.
Also wird er sicher den IP-Stack von PC und ESP verwenden - und dort 
gibts nun mal TCP oder UDP.

Sascha

ArduStemmi schrieb:
> Meine Absicht ist, dass über TCP zu tun.

Dann solltest Du Dich mit den tatsächlichen Eigenschaften von TCP 
beschäftigen und nicht irgendwelche wirren Wunschvorstellungen 
hineininterpretieren. Bei der Gelegenheit solltest Du Dich mit den 
fundamentalen Unterschieden zwischen "stream oriented" und "message 
oriented" Prokollen informieren. Ein weiteres wichtiges Stichwort ist 
"NAGLE".

Wie kommst Du überhaupt auf die irrige Annahme, dass bei TCP die 
zeitnahe Übertragung von Nachrichten fester Länge sichergestellt wird? 
TCP sichert nur zu, dass die vorne hineingesteckten Zeichen irgendwann 
und in korrekter Reihenfolge beim Empfänger ankommen.

> Oder: Jemand erklärt mir, ob es irgendwo einen Puffer gibt, den mein
> Programm vollschreibt.

Ja, es gibt etliche Puffer auf Sende- und Empfangsseite. Insbesondere 
ist auch zu beachten, dass die von Empfangsfunktionen wie z.B. recv() 
gelieferte tatsächliche Länge an empfangenen Daten überhaupt nichts mit 
den Größe des gesendeten Datenpuffers zu tun haben muss. Der an recv() 
übergebene Längenparameter (size_t len) gibt auch nur die maximale 
Datenblockgröße an, nicht die in jedem Fall zu liefernde.

ArduStemmi schrieb:
> Und nun?

Dann analysiere diese Daten! Die TCP/IP-Spezifikation ist frei 
zugänglich, es gibt Unmengen an Publikationen zu diesem Thema, usw..

Was sollen wir hier mit solch einem blöden Screenshot anfangen? Wenn Du 
möchtest, dass hier jemand bei der Analyse Deines Mitschnitts 
assistiert, solltest Du ihn in einem brauchbaren Datenformat hochladen. 
Falls Du Dich auch nur ansatzweise mit der Funktion von Wireshark 
vertraut machen würdest, wüsstest Du das richtige Format.

ArduStemmi schrieb:
> Ich habe jetzt mal die ganzen Nullen in 1 umgewandelt und siehe da,
> jetzt passt es! Wenn also im Nachrichtenstring genug Bits gesetzt sind,
> scheint es zu funktionieren.
Ein String kann kein Null-Byte enthalten da dieses als 
Stringendekennzeichen verwendet wird.
Warum nimmst du im ESP eine Stringfunktion zum einlesen? Am Sender 
arbeitest du doch auch mit einem Bytearray.

Sascha

Was vielleicht nicht durchkam ...

TCP verwendet man, um sicherzustellen dass etwas genau so rauskommt 
wie's reingeht. zB fuer einen Filetransfer. Das TCP macht dann die 
noetigen retries.

UDP verwendet man wenn es nicht so genau drauf ankommt ob die Daten 
vollstaendig sind, wenn es aber drauf ankommt, daass etwas zeitnah 
rauskommt. zB Audio oder Video. Dort ist es egal, dass ob mal ein Sample 
oder ein Frame fehlt, wichtig ist, dass sofort etwas kommt.

Daher zerscheibelt man fuer TCP den Transfer sinnvollerweise auf die 
maximale Blockgroesse, fuer UDP aber eher auf eine Groesse, die 
kontinuierliches Senden bringt.

Decius schrieb:
> Laut TCP Standard ist für das Aknowledge ein Zeit von bis zu 500ms
> zulässig. Wenn es also schnell gehen muss, bleibt nur UDP.

Die obige Aussage ist etwas unpräzise. Laut TCP-Standard muss der 
Empfänger ein Acknowledge innerhalb von 500ms senden. Das bedeutet aber 
nicht, dass es innerhalb dieser Zeit beim Sender eintreffen muss. Ganz 
im Gegenteil kommt es bei Netzwerkverbindungen, die eine zu geringe 
Übertragungsbandbreite besitzen, in solchen Fällen sogar zu Datenstau 
auf beiden Seiten der Verbindung. Auf der einen Seite stopft der Sender 
seine Retransmits in den Router, auf der anderen Seite der Empfänger 
seine Acknowledges. Bessere Routerimplementierungen entfernen daher bei 
überlasteten Leitungen bzw. Puffern selbsttätig einen Teil der 
Retransmits. Wie die Erfahrung nämlich zeigt, werden die o.a. Datenstaus 
in vielen Fällen gar nicht durch eine zu geringe Bandbreite verursacht, 
sondern eine kleine Störung führt zu Retransmitlawinen.

Der Fachausdruck für Leitungen, die u.a. von solchen (und auch einigen 
anderen) Problemen betroffen sind, heißt "long fat pipe". Es würde bei 
weitem den Rahmen dieses Threads sprengen, all diese Themen zu 
diskutieren.

ArduStemmi schrieb:
> Herzlichen Dank für Deine ausführliche Beschreibung. Das kann ist im
> Wesentlichen, dass was ich bisher nocht verstanden hatte. Ich habe Daten
> gelesen und entweder erste oder letzte Teile als Teiler eines an Sich
> leeren Strings vorgefunden. Dazu kam noch erschwerend, dass ich auf der
> ESP Seite Charts eingelesen habe und Bytes erwartet hatte.
>
> Na gut. Ich werde jetzt byteweise lesen und Schreiben und einen
> Ringpuffer verwenden. Da kann ich mit dem Datentyp Byte arbeiten und
> brauch mir keine Gedanken um Sonderzeichen machen.
>
> Danke für Eure Geduld!
>
> Ich hab dann doch wieder etwas gelernt.

Nein nein, hier werden mal wieder Halbwissen und Märchen durch die 
Gegend geschoben, bis sie als "Wahrheiten" gelten...

Du brauchst weder Byteweise lesen noch byteweise schreiben. Das Einzige, 
was Du nicht machen darfst, ist die Returnwerte von send() und receive() 
ignorieren. Sehr Viele wissen das auch nach 30 Jahren Lebensdauer von 
TCP/IP nicht!

Also: Du machst einen recv() und wartest auf z.B. 10 Zeichen. Der 
Standardfehler ist zu denken, daß Du bei "Erfolg" des recv() (also 
Returnwert != -1) auch automatisch 10 Zeichen bekommen hast. In Aller 
Regel sind Transfers einer kleinen Zeichenmenge "atomisch," d.h. wenn 
eine Seite 10 Zeichen in einem send() Aufruf über TCP reinsteckt, kriegt 
die Andere Seite meistens auch die 10 Zeichen in einem einzigen Aufruf 
zurück.

Es kann aber durchaus sein, daß der send() Aufruf die 10 Zeichen in 2 
(low level) Pakete zerstückelt oder einen Teil in ein vorhergehendes 
Paket integriert und den Anderen Teil in ein Weiteres. Dann gibt Dir ein 
recv() mit 10 angeforderten zeichen mglw. nur einen Returnwert von 6 
zurück, d.h. Du musst grundsätzlich in einer Schleife deinen 
Applikationspuffer voranstellen und solange weitere recv()s ansetzen, 
bis alle Daten zusammen sind (oder selbst verständlich bis ein Timeout 
eingetreten ist oder ein Fehler). Gleiches gilt auch für das send()! Ein 
send() mit 10 Zeichen kann auch einen Erfolgswert von 6 zurückgeben, 
dann muss die Applikationsseite genauso nachsynchronisieren.

Solange Du diese Regeln befolgst, kannst Du fest davon ausgehen, daß TCP 
Dir genau den Datenstrom auf der Anderen Seite gibt, den Du auf der 
einen Seite hereinsteckst. Das ist die Definition von TCP, und die Sache 
ist nun lang genug auf der Welt, daß man davon ausgehen kann, daß eine 
konforme Implementation das auch garantiert.

Manche TCP/IP Implementationen erlauben es, dem send() und recv() einen 
Parameter MSG_WAITALL mitzugeben, der erst dann zurückkehrt, wenn alle 
angeforderten Zeichen im Sender- bzw. Empfangspuffer verarbeitet sind. 
Wo es das nicht gibt oder das flag nicht benutzt wird, muss es auf 
Applikationsebene geschehen.

All das entbindet Dich natürlich nicht von der Pflicht, das Schicht 5 
Protokoll sauber zu implementieren, d.h. zu jedem Zeitpunkt genau zu 
wissen, wieviele Zeichen Du senden bzw. empfangen musst (davon hängt 
u.A. ab, wie Du die Schleife aufsetzt).

Nachtrag: Manche Leute fragen sich nun, wie es passieren kann, dass ein 
"kleiner" Datensatz von einem Sender zerstückelt wird. Das hängt mit dem 
sogenannten "Fenster" zusammen. Während der Paketübertragung auf TCP 
Ebene meldet jede Seite einer offenen Verbindung der Anderen Seite in 
jedem Paket, wieviel Platz noch im Empfangspuffer zur Verfügung steht 
(das "Fenster"). Der Sender darf (auf TCP Ebene) nicht mehr Bytes in 
einem Paket senden, als das momentane Fenster des Empfängers gross ist.

Ein typisches Szenario in unsychnronisierten Protokollen (wo also eine 
Seite fortwährend "neue" Pakete schickt, ohne auf ein 
applikatiosseitiges ACK zu warten) ist dass die empfängerseitige task, 
die die Daten wegschaufelt, hängt oder durch einen lockout selten dazu 
kömmt, Daten aus dem im TCP stack vorgehaltenen Puffer auszulesen. Was 
man im Sniffertrace hier sehr gut sehen kann, ist dass das Fenster dann 
immer kleiner wird. Das führt dann im Nachgang dazu, dass der Sender 
seinen eigenen Sendepuffer immer voller macht, und wenn der unter einen 
Schwellwert fällt, wird ein Aufruf zu send() nur noch einen Teil seiner 
Daten unterbringen können, und das socket API meldet das eben dadurch, 
dass der Returnwert von send() kleiner ist als die angeforderte 
Datengröße.

Das Ganze darf man sich gerne als Stossdämpfer vorstellen. Die 
Schluckaufs in der Kommunikation werden durch die von TCP gemanagten 
verbindungsinternen Puffer abgefedert, aber wenn die zu heftig werden, 
ist das auch für die Applikation sichtbar.

Diese Ausführungen haben aber erstmal nichts mit retransmissions zu tun. 
TCP interne retransmissions stecken nicht "mehr" Daten in einen 
Empfangspuffer, sondern sie synchronisieren die Sende- und 
Empfangspuffer miteinander.

Wenn das Applikationsprotokoll allerdings fehlertolerant ist (was es 
selbstverständlich sein sollte), also timeouts implementiert und 
eigenständig nach Ablauf eines Timeouts Daten nochmal sendet, sind das 
für TCP "neue" Daten, die genauso den Stossdämpfer beanspruchen.

Ruediger stellt die Sachverhalte zu den Puffer- und Fenstergrößen in TCP 
sehr gut und prägnant dar, ohne Fehler durch Vereinfachungen o.ä. zu 
begehen.

Ruediger A. schrieb:
> All das entbindet Dich natürlich nicht von der Pflicht, das Schicht 5
> Protokoll sauber zu implementieren, d.h. zu jedem Zeitpunkt genau zu
> wissen, wieviele Zeichen Du senden bzw. empfangen musst (davon hängt
> u.A. ab, wie Du die Schleife aufsetzt).

Im TCP/IP-Schichtenmodell befindet sich die Applikation auf Schicht 4. 
Wenn es darum ginge, ein Kommunikationsprotokoll auf SSL, HTTP o.ä. 
aufzusetzen, z.B. indem man eine Anwendung für einen Webserver oder 
Servlet-Container implementiert, könnte man hier etwas unpräzise von 
Schicht 5 sprechen. Der Threadersteller verwendet jedoch nackte 
Socket-Schnittstelle, die die Funktionen der Transportschicht auf 
Schicht 3 bereitstellt. Somit befindet sich sein Programm auf Schicht 4.

Ruediger A. schrieb:
> Wenn das Applikationsprotokoll allerdings fehlertolerant ist (was es
> selbstverständlich sein sollte), also timeouts implementiert und
> eigenständig nach Ablauf eines Timeouts Daten nochmal sendet, sind das
> für TCP "neue" Daten, die genauso den Stossdämpfer beanspruchen.

Nein, in vielen Fällen sollte man keine eigenen Retransmits durchführen, 
insbesondere dann nicht, wenn sich die hierfür relevanten Timeouts noch 
innerhalb der TCP/IP-Timeouts bewegen. Ansonsten kann dies zu einer 
weiteren Verstopfung des Kommunikationskanals führen. Kürzere Timeouts 
auf Empfängerseite können hingegen durchaus sinnvoll sein, um die 
Anwendung z.B. in einen sicheren Zustand zu überführen, z.B. Antriebe 
anzuhalten.

Nur wenigen Entwicklern bekannt, gibt es bei TCP auch noch die sog. 
Out-of-band-Signalisierung, mit der man hochpriore Daten an den schon in 
den Datenpuffern befindlichen "vorbeischmuggeln" kann, auch wenn das 
Fenster schon gefüllt ist. Allerdings sollte man bedenken, dass man sich 
hierdurch auch gewaltige Synchronisationsprobleme innerhalb der eigenen 
Applikation einhandeln kann. Die OOB-Signalisierung wird z.B. vom 
TELNET-Protokoll unterstützt, um Signale zu schicken, z.B. um einer 
Shell zu signalisieren, dass sie ein hängendes Programm beenden soll.

Bei der Implementierung von Tunnelprotokollen, z.B. mittels SSH, trifft 
man auf das sog. TCP-over-TCP-Problem, d.h. eine stockende "äußere" 
TCP-Verbindung bewirkt Retransmits auch auf "inneren" TCP-Verbindungen. 
Deswegen verwenden viele Tunnelprotokolle stattdessen UDP für ihre 
äußere Verbindung oder klemmen sich zwischen Internet- und 
Transportschicht und verwenden UDP nur für Steuerdaten.