none
UDP-Socket in .NET RRS feed

  • Frage

  • Das UDP-Protokoll ist ein Verbindungsloses, schnelles und unzuverlässiges Protokoll, welches aufgrund auch dieser Eigenschaften für viele performancekritische Vorgänge wie beim DNS-System funktioniert.

    Ich wollte nun mit dem .NETFramework ein Socket zum Übertragung von UDP öffnen. Sieh auch:

    Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
    
    //Socket vorbereiten
    
    byte[] buffer = //mein Puffer; 32-Zeichen
    
    s.Send(buffer);
    

    Da UDP ja unzuverlässig ist, können Daten unterwegs verloren gehen usw. Doch meine Frage ist, wie sich das beim Benutzen von Socket.Read() auswirkt. Auf meinen eigenen Rechner kann ich das nicht testen, da zwischen diesen selbst und auch zwischen eine weiteren Rechner eine perfekte Verbindung herrscht, und die Daten sich weigern verloren zu gehen. 

    Wenn ich jetzt mit Socket.Read() arbeite und eine "echte" Verbdinung habe, kommen die Daten dann in reinform an, also mit fehlenden Teilen oder ohne Ankunft usw. oder versucht das .NET-Framework da was zu ändern?

    Vielen Dank für alle Antworten.


    © 2015 Thomas Roskop

    Germany // Deutschland

    Sonntag, 25. Januar 2015 20:41

Antworten

  • Hallo Thomas,

    auch bei UDP (siehe Wikipedia) wird auf Transportebene anhand der Länge erkannt, ob ein Paket vollständig ist - und bei Verwendung des Prüfsumme mit hoher Wahrscheinlichkeit ob die Daten Fehler aufweisen.

    Was bei UDP (im Gegensatz zu TCP) fehlt ist ein Handshake. So können ganze Pakete verloren gehen und man muss über das eigene Protokoll sicherstellen, dass man alle Daten erhalten hat. Ein übliches Verfahren ist eine laufende Nummer für eine Folge von Übertragungen.

    Falls Du immer noch beim "Datei übertragen" bist, so schaue Dir die RFC von NFS an - es sollte auch open source zu finden sein -, das in seiner Urform auf UDP präferiert und damit recht zuverlässig funktioniert (zumindest solange ich noch unter UNIX damit arbeitete ;)

    Gruß Elmar

    P.S.: Was das Testen angeht: Abstöpseln des Kabels (oder Stören des WLANs) sollte funktionieren.



    Sonntag, 25. Januar 2015 21:38
    Beantworter
  • Hallo Thomas,

    die maximale Paketgröße ist 65507 bytes (erster Google Eintrag). Und wie Elmar schon sagte, ein Packet bekommst du komplett. Dein 128Byte bekommst du also Komplett. 

    Grundlegend solltest du schauen, das du deine Packete so zusammen fast. Das du nach dem Verlust von anderen Packeten noch was mit ihnen anfangen kannst. Das musst du aber selber Implementieren. 

    Die Fälle die du betrachten musst sind ja klar.

    1.) Pakete können verloren gehen.

    2.) Die reihen folge der Pakete kann vertauscht sein.

    3.) Es können Pakete öfter ankommen.

    MFG

    Björn 

    • Als Antwort markiert Thomas Roskop Montag, 26. Januar 2015 12:21
    Montag, 26. Januar 2015 09:48

Alle Antworten

  • Hallo Thomas,

    auch bei UDP (siehe Wikipedia) wird auf Transportebene anhand der Länge erkannt, ob ein Paket vollständig ist - und bei Verwendung des Prüfsumme mit hoher Wahrscheinlichkeit ob die Daten Fehler aufweisen.

    Was bei UDP (im Gegensatz zu TCP) fehlt ist ein Handshake. So können ganze Pakete verloren gehen und man muss über das eigene Protokoll sicherstellen, dass man alle Daten erhalten hat. Ein übliches Verfahren ist eine laufende Nummer für eine Folge von Übertragungen.

    Falls Du immer noch beim "Datei übertragen" bist, so schaue Dir die RFC von NFS an - es sollte auch open source zu finden sein -, das in seiner Urform auf UDP präferiert und damit recht zuverlässig funktioniert (zumindest solange ich noch unter UNIX damit arbeitete ;)

    Gruß Elmar

    P.S.: Was das Testen angeht: Abstöpseln des Kabels (oder Stören des WLANs) sollte funktionieren.



    Sonntag, 25. Januar 2015 21:38
    Beantworter
  • Hallo,

    es UDP-Protokoll soll bei mir nur ganz kleine Daten übertragen, von der größe her wie eine DNS-Anfrage. Und es ist recth schwer so schnell das Kabel zu ziehen?

    Wenn ich also z.B. 64Bytes oder 128Bytes übertrage, dann werden diese also unter Umständen nur Teilweise (wenn überhaupt) beim Stream ankommen.

    Beispiel:

    Socket.Send( byte { 0, 1, 2, ... , 63 } )
    
    /* Transport */
    
    
    Socket.Receive( )
    -> byte kann entweder
       i) byte { 0, 1, 2, ... 63 }
       ii) byte { 0 } //Länge: 0 // Keine Ankunft
       iii) byte { 0, 2, ... } //Beschädigt, oder?
    


    © 2015 Thomas Roskop

    Germany // Deutschland

    Montag, 26. Januar 2015 05:47
  • Hallo Thomas,

    die maximale Paketgröße ist 65507 bytes (erster Google Eintrag). Und wie Elmar schon sagte, ein Packet bekommst du komplett. Dein 128Byte bekommst du also Komplett. 

    Grundlegend solltest du schauen, das du deine Packete so zusammen fast. Das du nach dem Verlust von anderen Packeten noch was mit ihnen anfangen kannst. Das musst du aber selber Implementieren. 

    Die Fälle die du betrachten musst sind ja klar.

    1.) Pakete können verloren gehen.

    2.) Die reihen folge der Pakete kann vertauscht sein.

    3.) Es können Pakete öfter ankommen.

    MFG

    Björn 

    • Als Antwort markiert Thomas Roskop Montag, 26. Januar 2015 12:21
    Montag, 26. Januar 2015 09:48
  • OK, danke für die Antworten. Was mir nicht klar war, war ob die Daten fehlerhaft ankommen können, aber das tun sie nicht. 

    Im Übrigen sind das nur einfache Anfragedaten, ähnlich einer DNS-Anfrage zum implementierung eines Traffics-Managers, wo eine IP-Addresse zurückgegeben wird.

    Vielen Dank!


    © 2015 Thomas Roskop

    Germany // Deutschland

    Montag, 26. Januar 2015 12:21