Cómo dividir recibido con boost asio udp sockets datagramas unidos

Question

He creado mi servidor y cliente UDP con boost :: asio udp sockets. Todo se veía bien antes de comenzar a enviar más datagramas. Vienen correctamente de cliente a servidor. Pero, están unidos en mi buffer en un solo mensaje.

utilizo

udp::socket::async_receive con std::array<char, 1 <<18> búfer

para realizar solicitudes asíncronas. Y recibir datos a través de devolución de llamada

void on_receive(const error_code& code, size_t bytes_transferred)

Si envío de datos con demasiada frecuencia (cada 10 milisegundos) Recibo varios datagramas simultáneamente en mi memoria intermedia con la devolución de llamada anteriormente. La pregunta es: ¿cómo por separado ellos? Nota: mis datagramas UDP tienen longitud variable. No quiero usar el encabezado adicional con el tamaño, porque hará que mi código sea inútil para los datagramas de terceros.

Answer 1

Creo que esto es una limitación en la forma en que boost :: asio maneja flujos de datos sin estado. Observé exactamente el mismo comportamiento cuando uso boost :: asio para una interfaz serial. Cuando estaba enviando paquetes con brechas relativamente grandes entre ellos, recibía cada uno en una devolución de llamada por separado. A medida que el tamaño del paquete creció y, por lo tanto, disminuyó la brecha entre los paquetes, llegó a una etapa en la que ejecutaría la devolución de llamada solo cuando el búfer estaba lleno, no después de recibir un solo paquete.

Si conoce exactamente el tamaño de los datagramas esperados, entonces su solución de limitar el tamaño del búfer de entrada es perfectamente razonable, ya que sabe exactamente a priori qué tan grande debe ser el búfer.

Si su congestión proviene de tener múltiples tipos de paquetes diferentes que se transmiten, por lo que no puede preasignar el búfer de tamaño correcto, entonces podría crear diferentes sockets en diferentes puertos para cada tipo de transacción. Es un poco más "hacky", pero dada la naturaleza virtualmente ilimitada de la disponibilidad de puertos efímeros, siempre y cuando no esté usando 20,000 tipos de paquetes diferentes que probablemente lo ayuden a salir tan bien.