2010-12-16 8 views
5

Ich habe Probleme mit UdpClient in C#. Ich streame Audio über das Internet zwischen zwei Clients.UdpClient - begrenzte Puffergröße?

Auf meinem Mikrofon, mit einer Abtastrate von 16 kHz, sende ich UDP-Pakete mit Audio mit 6400 Byte pro Paket. Diese kommen nie durch, außer dem letzten Paket, das normalerweise zwischen 1200-3400 liegt, seit ich die Aufnahme geschlossen habe. Wenn ich die Abtastrate auf 8kHz reduziere, sende ich Pakete mit 3200 Byte Nutzlast. Diese kommen immer aus irgendeinem Grund durch.

Also im Grunde wird alles über 3200 verpfuscht (hat keine genaue Zahl getestet, aber ...) Warum in aller Welt ist das? Ich dachte vielleicht der UdpClient interne Puffer ist zu klein oder so? Da streame ich Audiodatenpakete häufig gesendet.

ERHALTEN:

private void audioReceive(IAsyncResult asyn) 
    { 
     try 
     { 
      byte[] temp = audioSock.EndReceive(asyn, ref this.serverEP); 
      this.waveProvider.AddSamples(temp, 0, temp.Length); 

      this.textbox_display.Text = this.textbox_display.Text + " got bytes: " + temp.Length; 
      audioSock.BeginReceive(new AsyncCallback(audioReceive), null); 

     } 
     catch (Exception ez) 
     { 
      MessageBox.Show("audioReceive: " + this.textbox_nick.Text + "  " +ez.ToString()); 
     } 

    } 

ich keine offensichtlichen Fehler finden können. (Das asyn-Objekt für die Funktion ist null btw, ich brauche kein stateobject, aber das sollte nicht damit verbunden sein)

Ich weiß, UDP ist nicht zuverlässig, aber unter Berücksichtigung jeder einzelnen 3200-Größe Paket durchkommen und keine 6400 Größe riecht fischig zu mir, vor allem mit maximaler Größe ist was, 64kb?

Irgendwelche Ideen?

Antwort

2

Es ist möglich, dass Pakete, die die MTU überschreiten (was meiner Meinung nach ungefähr 1500 Bytes beträgt) verworfen werden. Zum Beispiel see this. Es hört sich so an, als ob Sie in eine Form davon geraten könnten. Damit es in verschiedenen Umgebungen zuverlässiger arbeiten kann, ist es möglicherweise besser, das Senden auf 1472 Byte pro Paket zu maximieren (um den Paket-Overhead zu berücksichtigen) und sie dann am empfangenden Ende wieder zusammenzusetzen.

Oder vielleicht nur TCP/IP verwenden. Selbst wenn ein Verlust akzeptabel ist, kann es ziemlich kompliziert sein, eine "einfache" UDP-Lösung zu verwenden. Ich arbeite an einem Produkt, das die Kommunikation für UDP und über TCP/IP unterstützt, und die UDP-Implementierung beinhaltet wahrscheinlich zehnmal so viel Code und hat eine viel größere Komplexität. Natürlich ist in unserer Situation kein Datenverlust akzeptabel, so dass sich einiges ändert.

+0

Mit der Tatsache, dass dieser Verkehr über das Internet geht, klingt das wie, was vor sich geht. –

+0

Um dies zu erweitern, werden IP-Pakete, die größer als die MTU sind, fragmentiert. Wenn alle Fragmente am Ziel ankommen, werden sie von der IP-Schicht wieder in das ursprüngliche IP-Paket (das das ursprüngliche UDP-Datagramm enthält) zusammengefügt.Wenn sie nicht alle ankommen, gibt es in UDP keinen Mechanismus, um eine erneute Übertragung anzufordern, so dass das gesamte Datagramm verloren geht. – EJP

+0

Danke, es ist jetzt klar! – KaiserJohaan

0

Sie sind garantiert 576 Bytes (548 für UDP-Payload) mit IPv4, aber Sie sollten mindestens 1472 Bytes (1444 UDP) für die meisten Benutzer zu halten.

können Sie testen, was MTU-Größe funktioniert ping wie hier beschrieben,

http://help.expedient.net/broadband/mtu_ping_test.shtml

libjingle verwenden einen sicheren Standard von 1280 Bytes (1252 UDP/IPv4, 1232 UDP/IPv6), die die garantierten Mindestspiele für IPv6,

http://code.google.com/p/libjingle/source/browse/branches/nextsnap/talk/session/tunnel/pseudotcpchannel.cc?spec=svn17&r=13