UDP Datei senden und empfangen

[jaenicke]

Via UDP kannst du allerdings nie wissen, ob du auch alle Teile der Datei bekommst und ob sie in der richtigen Reihenfolge sind. Wenn du also unbedingt UDP nutzen willst, musst du die Pakete markieren und beim Empfang entsprechend wieder zusammensetzen. Sich darauf zu verlassen, dass es schon klappen wird, könnte lustige / traurige Ergebnisse bringen.

Für Hole Punching ist UDP allerdings nicht erforderlich, Skype verschickt Dateien auch per TCP, alles andere wäre auch wenig sinnvoll. Mehr zu TCP Hole Punching:
http://en.wikipedia.org/wiki/TCP_hole_punching

[TTF]

Danke für die Antwort. Ich wollte es einfach über UDP machen, weil ich irgendwo gelesen habe, dass es TCP Hole Punching extrem schwierig sei und man dazu mit raw sockets arbeiten muss, was nur mit C so richtig möglich sei...
Momentan schaue ich mal, ob ich das mit der Nummerierung und Aneinanderreihung der Pakete hinkriege. Andernfalls bin ich froh, wenn ich mich wieder hierhin wenden darf

[sx2008]

Es gibt übrigens schon ein Protokoll das Dateien per UDP überträgt:
Trivial File Transfer Protokoll (TFTP)
Du kannst dir mal den RFC 1350 einpfeifen.

Wenn du genau dieses Protokoll verwendest dann brauchst du Client und Server nicht gleichzeitig entwickeln, sondern kannst einen Teil zunächst mit unabhängiger und funktionierender Software ersetzen.

[TTF]

Hmm danke, tönt interessant. Aber ich habe bei Wikipedia gelesen, dass es Standardmässig deaktiviert sei, da einige Würmer es zur Verbreitung benutzen...

Ich glaube ich bleibe mal vorerst bei UDP, da ich erstens schon ein paar Erfolge (wenn auch ziemlich lustige) erzielt habe und es sich besser erweitern lässt.

Wenns jemand interessiert, als Anhang ein Beispiel von einem eher etwas abstraktem Bild

[BUG]

Wenn du etwas ernsthaftes, nicht-Echtzeit-kritisches mit größeren Datenmengen (Nachricht >> 1 Datagram) implementieren möchtest, solltest du nicht nur wegen des Hole-Punching auf TCP verzichten. Insbesondere, wenn das ganze über das Internet gehen soll. TCP würde jahrzehntelang auf die Übertragung von Byte-Strömen durch das Internet optimiert.

Wenn du es dir um den Lerneffekt geht: Viel Spaß dabei.
Hier findest du mit dem XDT-Protokol ein Beispiel, wie man ein paar grundlegende Dinge angehen kann.

[TTF]

Zitat von BUG:

..., solltest du nicht nur wegen des Hole-Punching auf TCP verzichten. Insbesondere, wenn das ganze über das Internet gehen soll. TCP würde jahrzehntelang auf die Übertragung von Byte-Strömen durch das Internet optimiert.

Ich verstehe irgendwie den Sinn dieser Aussage nicht. Einerseits sagst du, das ich auf TCP verzichten soll, andereseits rühmst TCP in Sachen Übertragung. Wie hast du das genau gemeint?

[BUG]

Zitat von TTF:

Einerseits sagst du, das ich auf TCP verzichten soll, anderseits rühmst TCP in Sachen Übertragung.

Ich habe es anders gemeint

Nämlich im Sinne von:
Wenn man nicht etwas spezielles macht, sollte man bei TCP bleiben.
Es wäre ein riesiger Aufwand, ein Protokoll zu entwerfen, welches nur annähernd so durchdacht ist wie TCP.
Man macht das (afaik) in der Regel nur, wenn man 1. keine Zuverlässigkeit braucht und die Flusskontrolle + Stauvermeidung selbst übernehmen will (z.B. Echtzeit/Multimedia) oder 2. die zu übermittelnde Botschaft so kurz ist, das die Übertragung allein durch die Handshakes bedeutend verzögert wird (z.B. RPC).

[sx2008]

Zitat von TTF:

Ich glaube ich bleibe mal vorerst bei UDP, da ich erstens schon ein paar Erfolge (wenn auch ziemlich lustige) erzielt habe und es sich besser erweitern lässt

Also Trivial File Transfer Protokoll ist UDP und es ist so ziemlich das einfachste Protokoll mit dem man über UDP Dateien übertragen kann.
Jede Vorgehensweise die noch einfacher sein will oder irgendwas weglassen will wird nicht funktionieren.

Stell dir vor du willst einen neuen Zug erfinden.
Dann wäre es doch viel viel einfacher das bestehende Schienensystem zu verwenden, oder?
Du möchtest vielleicht ein neues Schienenprofil mit weniger Reibung erfinden.
Dan wäre es sehr geschickt dafür existierende Züge zu verwenden.
Regelrecht dumm wäre es Zug und Schienen neu zu erfinden wenn das Gesamtergebnis schlechter als das bisherige Standardsystem ist.

So und jetzt übertrage diese Analogie auf Client und Server.
Wenn du Client und Server gleichzeitig eintwickeln musst und ausserdem kaum eine Ahnung hast wie Netzwerkprotokolle funktionieren, tja dann wird es richtig schwierig.
Wenn aber z.B. der Server und das Datenprotokoll schon feststehen, dann ist es viel einfacher einen Client zu programmieren.