TCP/IP: Frage zur Datenübertragung / Protokoll PC <-> AVR

[Ethernet Neuling (Gast)]

Hallo zusammen,

ich beschäftige mich im Moment mit TCP/IP und möchte das Ganze auf einem 
AVR implementieren. Dazu möchte ich das NET IO von Pollin nutzen und zum 
Verstehen erst mal die Beispielprogramme hier aus dem Forum nutzen.

Bisher habe ich nur serielle Kommunikation eingesetzt. Dort hatte ich 
ein simples Protokoll mit Start ID (8 Bit), Parameter ID (8 Bit), 
Nutzdaten (32 Bit) und einer Checksumme (16 Bit). Die Länge ist immer 
fix gewesen und funktioniert auch ganz gut in meinem Haus.

Z.B.:
Parameter 1 -> Temperatur 1
Parameter 2 -> Temperatur 2
Parameter 3 -> Spannung
usw.

Zur Auswertung der Daten und zur Steuerung habe ich in C# ein kleines 
Tool geschrieben. Nur muss der PC immer an sein und sich in der Nähe 
meiner Platine befinden. Die einzelnen Parameter werden nacheinander 
zyklisch abgerufen. Daher nun der Versuch via Ethernet.

Soweit ich bisher gelesen habe ist TCP ein Datenstrom, aufgeteilt in 
mehrere Pakete. Das IP Protokoll dient zur Adressierung darüber liegen 
die Dienste (Webserver, Email usw.). Das .NET Framework bietet Sockets 
an um via TCP/IP zu kommunizieren. Soweit mein aktueller Wissensstand.

Ich frage mich nun, wie bilde ich z.B. mein Protokoll in TCP/IP ab? 
Damit ich meine Parameter abfragen und / oder manipulieren kann?
Bilde ich einfach in dem Datenstrom mein serielles Protokoll ab und 
müsste es, wie jetzt auch, parsen?

MfG
Ethernet Neuling

[Läubi .. (laeubi)]

Ethernet Neuling schrieb:
> Bilde ich einfach in dem Datenstrom mein serielles Protokoll ab und
> müsste es, wie jetzt auch, parsen?

korrekt, im Prinzip ist das aus Applikationssicht egal ob ein Serieller 
oder TCP Strom gelesen wird, es ist einfach eine Abfolge von Bytes. Der 
Rest ist deine Aufgabe.

[Ethernet Neuling (Gast)]

ok, danke.

[tobi (Gast)]

Läubi .. schrieb:
> Ethernet Neuling schrieb:
>> Bilde ich einfach in dem Datenstrom mein serielles Protokoll ab und
>> müsste es, wie jetzt auch, parsen?
>
> korrekt, im Prinzip ist das aus Applikationssicht egal ob ein Serieller
> oder TCP Strom gelesen wird, es ist einfach eine Abfolge von Bytes. Der
> Rest ist deine Aufgabe.

Wobei du bei TCP/IP den Vorteil hast, das die Daten in Paketen ankommen, 
Du Dir also weniger Gedanken machen musst wo Dein Telegramm 
anfängt/aufhört..
Zuminderst solange nicht fragmentiert wird oder mehr Pakete hereinkommen 
als Du verarbeiten kannst.

[Läubi .. (laeubi)]

Ich glaub ich nutz ein anderes TCP/IP als du... wird das jetzt Mode oder 
was?
TCP ist nicht Paketorientiert auf der Anwendungsschicht, und es wird 
auch nix verworfen oder Fragmentiert auf der Anwendungsschicht...

TCP definiert eine reine Stream-Sicht auf die Daten idr. mit einem 
Eingabe und einem Ausgabestream.

[Axel S. (a-za-z0-9)]

tobi schrieb:
> Wobei du bei TCP/IP den Vorteil hast, das die Daten in Paketen ankommen,
> Du Dir also weniger Gedanken machen musst wo Dein Telegramm
> anfängt/aufhört..

Ähh. Nein.

Anwendungsseitig ist TCP ein Stream. Das schaut selber gar nicht auf 
deine Daten. Ob du als Sender da einzelne Bytes reinschiebst oder Pakete 
konstanter Größe oder Pakete variabler Größe - das ist TCP völlig Wurst.

Natürlich verschickt der TCP-Stack die Daten auf dem Netzwerk wieder als 
Pakete. Aber das hat mit der Paketierung der Daten auf Anwendungsseite 
eher nix zu tun. Nur indirekt: wenn die Anwendung sehr langsam schreibt, 
schickt der TCP-Stack irgendwann auch ein "halbvolles" Paket raus statt 
zu warten bis  er genug für eine MTU hat. Wenn die Anwendung also z.B. 
immer 6 Bytes schreibt und dann "eine Ewigkeit" nix, dann werden die 
TCP-Pakete auf dem Netz natürlich auch immer nur 6 Bytes Daten 
enthalten. Und vergleichsweise viel mehr Header, was die Sache 
ineffizient macht.


XL