UDP Datei senden und empfangen

[TTF]

Hallo liebe Delphianer,

Als erstes wollte ich mich bedanken bei diesem genialen Forum, in dem die Leute so schnell und gut antworten wie fast nirgends sonst.

Mein Problem:
Ich möchte gerne Dateien über UDP versenden. Für den Anfang erst einaml mit den Komponenten von Indy(oder andere, falls sie sich besser eignen).
Das Problem ist, dass ich auf keinen Fall auf TCP ausweichen kann, wie überall vorgeschlagen, denn ich möchte die Technik des Hole Punchings verwenden, welches sich an eine Ungenauigkeit von UDP anlehnt. Also kann man eigentlich sagen, mein "Vorbild" ist Skype(kann auch Dateien senden und benutzt UDP): http://www.heise.de/security/artikel...en-270856.html

Meine bisherigen Versuche sind alle schon gescheitert, bevor das Programm fertig compiliert war...:roll:
Meistens mit dieser Meldung:
[dcc32 Fehler] Unit1.pas(55): E2250 Es gibt keine überladene Version von 'SendBuffer', die man mit diesen Argumenten aufrufen kann

Hat jemand eine Idee, wie man das lösen kann?

[Aphton]

Ich schlage vor, dass du lernst, wie man mit den Komponenten erst überhaupt umgeht. Kompliziertere Sachen sollten erst später kommen, da du sonst dir die Zähne daran ausbeißt und gar keine Freude mehr am Ganzen findest.

Und der Fehler den du da beschreibst, sollte man wenn man das ABC von Delphi kann, schnell beheben können.

Schau dir mal paar Grundlagentutorials an. Vorallem Funktionen/Prozeduren/Methoden + Rümpfe/Parameter

[TTF]

Naja, wie dem auch sei...
Mit einer eigenen Minidatei habe ich es nun hingekriegt. Das komische ist aber wenn ich es mit einer *.txt Datei versuche, die nicht allzu viel grösser ist und erhalte die Exception
"Zu wenig Arbeitsspeicher". Ich kann mir beim besten Willen nicht vorstellen, dass das stimmen kann. Weiss jemand woran das liegen könnte?
Die Meldung kommt auch ohne abschicken, nur beim Laden in ein Byte-Array.

[Aphton]

Vielleicht lädst du falsch.. Wir können nicht hellsehen, daher musst du genug Information liefern!
=P

[TTF]

Ich habe den Fehler gefunden und es funktioniert auch soweit(Habe die Länge der Datei falsch zugewiesen). Aber wenn ich die Datei nach dem Senden wieder abspeichere steht in der geladenen *.txt nebst dem ursprünglichen Text noch etwas anderes nämlich ein komisches Zeichen. Sieht ungefähr so aus: _|. Und wenn ich es mit einem *.bmp versuche geht es gar nicht(das erzeugt Bild lässt sich nicht richtig öffnen).
Anscheinend habe ich wohl noch den einen oder anderen Fehler drin:

Delphi-Quellcode:

//Senden
var
  Stream : TStream;
  i : Integer;
  Len : Longint;
  Datei : TIdBytes;
begin
  Stream := TFileStream.Create('D:\Testbild.bmp', fmOpenRead);

  Len := Stream.Size;

  SetLength(Datei,Len);

  for i := 0 to Len -1 do
  begin
    Stream.Read(Datei[i], SizeOf(Datei[i]));
  end;

  Stream.Free;

  IdUDPClient1.SendBuffer(Datei);
end;

//Empfangen:

var
  Stream : TStream;
  Len, i : Integer;
begin
  Stream := TFileStream.Create('D:\testbild1.bmp', fmCreate);

  Len := Length(AData);
  Stream.Write(Len, SizeOf(Len));

  for i := 0 to Length(AData)-1 do
  begin
    Stream.Write(AData[i], SizeOf(AData[i]))
  end;

  Stream.Free;
end;

Wäre froh, wenn sich jemand das mal anschauen könnte.

[TTF]

Es hat nun geklappt. Ich hatte noch unnötige Überreste von meiner eigenen Datei drin, wodurch das bmp ungültig wurde:wall:

[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:-D

[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:

Zitat von BUG (Beitrag 1233496)

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

Zitat von TTF (Beitrag 1233529)

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

Ich habe es anders gemeint :mrgreen:

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

[TTF]

Ach so hast du das gemeint:mrgreen:.
Theoretisch habe ich nichts dagegen, auf TCP umzusteigen.
Aber ich kapiere irgendwie nicht, wie Hole Punching bei TCP funktioniert. Da das Protokoll nicht wie UDP verbindungslos ist merkt es ja sofort, ob die Anfrage fehlschlägt. Und dann haben wir ja kein "Loch" mehr in der Firewall. Oder versteh ich das jetzt falsch? Kann mir das bitte jemand genauer erklären?

[Aphton]

Firewall? Wat? Weißt du überhaupt, was Holepunching ist?

[TTF]

Ja ich weiss, ich habe mich unpräzise ausgedrückt und bin davon ausgegangen, das zur heutigen Zeit jeder Router auch eine interne Firewall hat...

PS: Ich fänds noch nett, wenn du mich nicht wegen jedem Scheiss fertigmachst.

[Aphton]

Das Mapping der internen und externen Ports über die NAT (Network Addresss Translation) hat afaik absolut gar nichts mit einer Firewall zu tun!

Edit:

Zu deinem PS... Tut mir Leid, aber nein. Wir sind hier in einem Forum, wo Wissen ausgetauscht wird. Leute die dieses Thread hier nachher bei ihren Problemen lesen werden, sollten keine falsche Informationen bekommen.

Ich mache dich nicht fertig, ich korrigiere dich; jetzt bist du schlauer! Oder willst du nicht schlauer werden?

Die Art, wie ich antworte soll lehren, dass du nächstes Mal genauer drüber nachdenkst, wenn du etwas schreibst!

[sx2008]

Zitat:

Zitat von TTF (Beitrag 1233484)

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.

[BUG]

Zitat:

Zitat von Aphton (Beitrag 1233697)

Ich mache dich nicht fertig, ich korrigiere dich; jetzt bist du schlauer! Oder willst du nicht schlauer werden?

Ein bisschen freundlicher hätte nicht geschadet :|

Zitat:

Zitat von Aphton (Beitrag 1233697)

Wir sind hier in einem Forum, wo Wissen ausgetauscht wird. Leute die dieses Thread hier nachher bei ihren Problemen lesen werden, sollten keine falsche Informationen bekommen.

Ich denke, diese Leute hätten sich auch über eine Erläuterung gefreuen, warum die Informationen falsch sind.
Ein "Wat?" hilft denen genauso wenig wie es TTF hilft :mrgreen:

[TTF]

Doch natürlich möchte ich schlauer werden:-D, aber es funktioniert ja auch, wenn der Computer direkt am Netz hängt, also ohne Router. Wie gesagt, ich habe mich unpräzise ausgedrückt und hätte besser NAT schreiben sollen.