AVR Webserver über Netzwerk verbinden

[Alexander K. (alexander_43)]

Hallo!

ich habe die Hardware der AVR Ethernet 8 Kanal I/O Karte von Ulrich 
Radig http://www.ulrichradig.de/home/index.php/avr/avr-ether-8-i-o 
aufgebaut und es läuft soweit alles einwandfrei (HTTP-Webserver).
Nun möchte ich aber zwei (oder später auch mehr) dieser Schaltungen über 
das Netzwerk verbinden, sodass diese miteinander kommunizieren können um 
ein paar Bytes Daten auszutauschen.
Da ich mich nicht ganz so tief mit Netzwerkprotokollen auskenne, 
bräuchte ich von euch mal einen Tipp, wie ich das am besten realisieren 
kann. Geht so etwas mit einfachen TCP/IP Datenpaketen oder brauche ich 
ein Protokoll wie zum Beispiel Telnet, was ja auch schon in der oben 
genannten Firmware implementiert ist? Mit Netzwerktechnik allgemein (IP, 
Mac, Subnet etc.) kenne ich mich aus; es geht nur um das Protokoll.

Vielen Dank für eure Hilfe im Voraus!

[Noch einer (Gast)]

So etwas wie Telnet brauchst du nicht unbedingt. Du kannst dir auch 
etwas einfacheres ausdenken.

Bei einer TCP Verbindung kommen am anderen Ende genau die selben Bytes 
heraus, die du am einen Ende hinein schiebst.

Wenn dir so etwas ausreicht, kannst du die ganzen Protokolle ignorieren.

[M.K. B. (mkbit)]

TCP/IP reicht vollkommen aus und bietet dir einen bidirektionalen 
Bytestrom.

Du musst allerdings in deiner Programmlogik erkennen, wenn die 
Verbindung abgebrochen ist und eine neue herstellen.

Da TCP nur sicherstellt, dass die Bytes beim Empfänger in der richtigen 
Reihenfolge ankommen, solltest du dir ein kleines eigenes Datenformat 
überlegen, damit du den Start und das Ende deiner Daten erkennen kannst.
Wahrscheinlich werden die Daten beim Empfänger in den gleichen Blöcken 
ankommen, wie dies von Sender abgeschickt werden. Darauf würde ich mich 
aber nicht verlassen, weil die Blockgröße sich auch ändern kann und dann 
bekommst du nicht mehr alles Daten auf einmal.

[A.. P. (arnonym)]

M.K. B. schrieb:
> Wahrscheinlich werden die Daten beim Empfänger in den gleichen Blöcken
> ankommen, wie dies von Sender abgeschickt werden. Darauf würde ich mich
> aber nicht verlassen, weil die Blockgröße sich auch ändern kann und dann
> bekommst du nicht mehr alles Daten auf einmal.

Eben das ist ja der Sinn eines Datenstroms, wie du es ja selber schon 
gesagt hast. Der Empfänger kann sowieso nicht wissen, in welchem "Block" 
die Daten abgeschickt wurden und ob diese irgendwie zusammengehören, da 
sie ja beim Empfänger zu einer langen Datenwurst zusammengesetzt werden, 
deren Anfang und Ende zunächst einmal nur durch das Öffnen und Schließen 
einer Verbindung festgelegt sind. Daher ist es sowieso Aufgabe des 
höheren Anwendungsprotokolls, einen sogenannten Datenrahmen zu erzeugen. 
Irgendein Protokoll wird sich det TO so oder so überlegen müssen für 
seine Daten. Ob es nun so etwas kompliziertes wie HTTP ist oder etwas 
eigenes, einfaches.

Wenn es ausreichend ist, dass pro Verbindung nur eine Dateneinheit 
verschickt wird, z.B. ein String oder eine Zahl, dann würde es ja z.B. 
ausreichen, zumächst dem Empfänger zu sagen, was für ein Datentyp jetzt 
kommt und wie lange dieser ist. Danach kommt die Information. 
Umschlossen wird dann dieser Informationsblock dann eben durch das 
Öffnen und Schließen der TCP-Verbindung. Sollen hingegen mehrere logisch 
voneinander getrennte Informationen über dieselbe Verbindung gehen, so 
muss man sich eben schon Gedanken über ein entsprechendes Framing 
machen. Da kanm man sich ja dann von bekannten Protokollen die 
benötigten Sachen zusammensuchen.

[Stefan F. (Gast)]

Bei UDP kann man sich hingegen darauf verlassen, dass ein Block genau so 
am Stück den Empfänger erreicht - wenn er überhaupt ankommt. Denn genau 
das ist bei UDP nicht mehr automatisch garantiert.

Bei UDP ist man auf die kleinste Block-Größe der ganzen 
Übertragungsstrecke beschränkt. 1KB geht eigentlich immer, bei größeren 
Blöcken muss man prüfen.

Bei UDP ist nicht garantiert, dass die Blöcke in der korrekten 
Reihenfolge beim Empfänger ankommen.

Ich vergleiche UDP Pakete gerne mit Postkarten. Es ist schön einfach, 
wenn man die Nachteile akzeptieren kann.

[Alexander K. (alexander_43)]

Vielen Dank für eure Antworten!

Ich denke, ich werde es mal mit UDP probieren, denn so wie ich das 
verstanden habe, kann ich einfach ein UDP Paket verschicken und es kommt 
dann (normalerweise) beim Empfänger an und ich muss mich nicht um den 
Verbindungsauf- und Abbau kümmern.
Weiß vielleicht jemand, in welcher Datei des Radig-Webservers ich den 
Funktionsprototyp/Befehl etc. finde, um UDP Pakete zu versenden? Oder 
hat das jemand schon mal gemacht?