2010-12-16 8 views
5

Tengo problemas con UdpClient en C#. Estoy transmitiendo audio a través de Internet entre dos clientes.UdpClient - limited buffersize?

En mi micrófono, con una frecuencia de muestreo de 16khz, envío paquetes UDP con audio con 6400 bytes por paquete. Estos nunca pasan, excepto el último paquete, el cual usualmente es alrededor de 1200-3400, algo desde que cerré la grabación. Cuando reduzco la frecuencia de muestreo a 8khz, envío paquetes con una carga útil de 3200 bytes. Estos siempre pasan por alguna razón.

Así que básicamente cualquier cosa por encima de 3200 se estropea (no se ha probado un número exacto pero ...) ¿por qué diablos es esto? Estaba pensando que quizás el buffer interno de UdpClient es demasiado pequeño o algo así? Dado que transmito paquetes de audio se envía con frecuencia.

reciben:

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()); 
     } 

    } 

no puedo encontrar ningún defecto obvio. (El objeto asyn para la función es nulo por cierto, no necesito usar un stateobject, pero eso no debe relacionarse con esto)

Sé que UDP no es confiable, pero considerando cada paquete de 3200 tamaños pasa a través y ningún tamaño 6400 me huele a pescado, especialmente con un tamaño máximo es de 64 kb?

¿Alguna idea?

Respuesta

2

Es posible que los paquetes que exceden la MTU (que creo que es alrededor de 1500 bytes) sean descartados. Por ejemplo, see this. Parece que puede encontrarse con alguna forma de esto. Para permitir que funcione de manera más confiable en diferentes entornos, puede ser mejor maximizar el envío a 1472 bytes por paquete (para permitir la sobrecarga del paquete) y luego volver a montarlos en el extremo receptor.

O tal vez solo use TCP/IP. Incluso si alguna pérdida es aceptable, puede ser bastante complejo hacer que funcione una solución UDP "simple". Trabajo en un producto que admite comunicaciones para UDP y sobre TCP/IP, y (conjeturas) que la implementación de UDP involucra probablemente 10 veces más código y tiene una complejidad mucho mayor. Por supuesto, en nuestra situación, no es aceptable la pérdida de datos, por lo que eso lo cambia un poco.

+0

Con el hecho de que este tráfico pasa por Internet, esto suena como lo que está pasando. –

+0

Para ampliar esto, se fragmentarán los paquetes de IP más grandes que el MTU. Si todos los fragmentos llegan al destino, se reensamblarán en el paquete IP original (que contiene el datagrama UDP original) por la capa IP.Si no todos llegan, no hay ningún mecanismo en UDP para solicitar una retransmisión, por lo que se perderá todo el datagrama. – EJP

+0

¡Gracias, está claro ahora! – KaiserJohaan

0

Tiene una garantía de 576 bytes (548 para la carga UDP) con IPv4, pero debe mantener al menos 1472 bytes (1444 UDP) para la mayoría de los usuarios.

Puede probar qué tamaño MTU funciona por medio de ping como se describe aquí,

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

libjingle utiliza un defecto de seguridad de 1280 bytes (1252 UDP/IPv4, 1232 UDP/IPv6), que coincide con el mínimo garantizado para IPv6,

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

Cuestiones relacionadas