Para los gurús de difusión UDP: problemas para lograr una transmisión UDP de audio de gran ancho de banda a través de WiFi(802.11N y 802.11G)
bandwidth broadcast (5)
Estoy intentando enviar audio multicanal a través de WiFi desde un servidor a varias computadoras cliente usando transmisión UDP en una red privada.
Estoy usando un software llamado Pure Data, con una herramienta de difusión UDP llamada netsend ~ y netreceive ~. El código está aquí: http://www.remu.fr/sound-delta/netsend~/
Para abreviar, puedo enviar 9 canales a una computadora cliente en una red punto a punto, pero cuando trato de transmitir a 2 clientes (aún no he probado más), obtengo sin sonido. Puedo comprimir el audio y enviar 4 canales comprimidos (aproximadamente 10% de tamaño sin comprimir) a través de la difusión UDP a 2 clientes con éxito. O puedo enviar 1 canal por transmisión UDP a 2 clientes, con algunas fallas técnicas.
El enrutador WiFi es un Linksys WRT300N. Todas las computadoras están ejecutando Windows XP. Las direcciones IP son 192.168.1.x, con máscara de subred 255.255.255.0 y la dirección de difusión de la subred: 192.168.1.255.
Tengo curiosidad: ¿qué ocurre con los paquetes de transmisión UDP en el enrutador? Si tengo una máscara de subred de 255.255.255.0, ¿el enrutador genera 254 paquetes por cada paquete enviado a la dirección de difusión?
Mi ancho de banda WiFi es de al menos 100Mbps, pero parece que no puedo enviar audio de más de 10Mbps por transmisión UDP a múltiples clientes.
¿Qué me impide enviar audio hasta el límite de ancho de banda del WiFi?
cualquier sugerencia para modificaciones de código de socket, configuraciones de red, configuraciones de enrutadores, modificaciones de subred ... todo muy apreciado!
gracias Nick
Tengo curiosidad: ¿qué ocurre con los paquetes de transmisión UDP en el enrutador? Si tengo una máscara de subred de 255.255.255.0, ¿el enrutador genera 254 paquetes por cada paquete enviado a la dirección de difusión?
No, el "enrutador" no genera 254 paquetes individuales. Además, sospecho que el protocolo aprovecha las direcciones de "multidifusión" en lugar de utilizar una dirección de "difusión".
Como el tráfico de difusión / multidifusión puede utilizarse de manera incorrecta, existen muchos equipos de red que limitan / bloquean por defecto dicho tráfico. Por supuesto, algunos protocolos esenciales (por ejemplo, ARP, DHCP) dependen de las direcciones de difusión / multidifusión para funcionar y no serán bloqueados por defecto.
Por lo tanto, podría ser una buena idea verificar las perillas de control de difusión / multidifusión en su enrutador.
¿Están todas las partes conectadas a través de WiFi o el remitente está utilizando una conexión por cable al Punto de acceso? Los datos de difusión se transmitirán como datos de unidifusión desde una estación a un punto de acceso y el punto de acceso retransmitirá los datos como tráfico de difusión / multidifusión, de modo que utilizará el doble del ancho de banda en el aire en comparación con cuando el remitente se sienta en el lado cableado el AP.
Al enviar un cuadro de unidifusión, el AP esperará un ACK de la estación receptora y retransmitirá el cuadro hasta que llegue el ACK (o se agote el tiempo de espera). Los fotogramas de difusión / multidifusión no son ACKed y, por lo tanto, no se retransmiten. Si tiene un entorno de radio ocupado / ruidoso, la probabilidad de que los paquetes caídos aumenten, potencialmente mucho, para el tráfico de multidifusión en comparación con el tráfico de unidifusión. En una aplicación de audio, esto ciertamente podría ser audible.
Además, el tráfico de difusión / multidifusión IIRC no utiliza el procedimiento RTS / CTS para reservar los medios que exarban el problema de los paquetes descartados.
En realidad, podría darse el caso de que varias transmisiones de unidifusión funcionen mejor que una sola transmisión de multidifusión en condiciones de radio no ideales dado que el ancho de banda agregado es lo suficientemente alto.
Si puede, le sugiero que use wireshark para oler el tráfico WiFi y echar un vistazo a la dirección de destino en el encabezado 802.11. Luego puede verificar si los paquetes realmente se transmiten o no por el aire.
Nueva información: el sistema definitivamente usa broadcast, no multicast.
Además, puedo transmitir con éxito 4 canales de audio sin comprimir (2.8Mbps) en una conexión cableada (cat5) en la misma configuración de transmisión UDP.
Cuando cambio a 802.11N (velocidad de conexión que alcanza entre 200 Mbps y 300 Mbps), no puedo obtener una transmisión ininterrumpida de 4 canales en transmisión UDP a 2 receptores. Pero si luego hago una transmisión punto a punto (a una IP individual en las mismas máquinas receptoras), aún con la misma conexión WiFi, puedo obtener una transmisión limpia de 4 canales (2.8Mbps).
Por lo tanto, parece que de alguna manera hay una sobrecarga adicional de ancho de banda para la transmisión UDP en comparación con una conexión directa UDP. Esta sobrecarga adicional hace que WiFi sea poco confiable como medio de transporte, aunque una conexión por cable seguirá funcionando.
¿Por qué la transmisión en WiFi es tan pobre y qué puedo hacer para mejorarla?
Su diseño está fallando debido a un error común con las velocidades de WiFi. Con 802.11n, el número de 300mb / s es la velocidad del enlace, no el ancho de banda real disponible para los datos del usuario o incluso la capa de IP. El ancho de banda efectivo está más cerca del mejor caso de 40mb / s, eche un vistazo a las preguntas frecuentes en SmallNetBuilder.com que lo explica con más detalle.
Su problema es causado por el algoritmo de control de velocidad del punto de acceso. Con la unidifusión, el punto de acceso rastrea la velocidad de datos a la que puede recibir cada receptor en particular y envía aproximadamente esa tasa. Con la multidifusión, el punto de acceso no sabe qué receptores están interesados en los datos, por lo que los puntos de acceso simples envían los datos a la velocidad más lenta posible (1Mb / s). Los puntos de acceso mejor implementados pueden enviar los datos a la velocidad que utiliza el cliente conectado más lento, y los mejores puntos de acceso utilizan IGMP snooping para ver quién recibe cada flujo de multidifusión IP, y elegirán la tasa más lenta de los receptores para esa transmisión .
La solución más simple es no utilizar la multidifusión cuando tiene una pequeña cantidad de receptores WiFi.