¿Fuerza el androide para enviar paquetes UDP inmediatamente?

Estoy experimentando con la conexión de mi As Galaxy a mi portátil a través de WiFi. Ambos dispositivos están conectados a un enrutador vía WiFi, y ambas partes utilizan Java.

Después de una conexión TCP me dio pings muy altos de vez en cuando, decidí basar la conexión en UDP, para poder controlar cuando los paquetes se envían realmente.

Sin embargo, parece que Android aún almacena paquetes UDP y no los envía inmediatamente. Esto, o se cierra WiFi completamente, si no hay datos salientes transmitidos por una fracción de segundo.

Primero, hice ping al teléfono a intervalos irregulares de aproximadamente una vez por segundo, enviando repetidamente peticiones de ping, siempre y cuando no se recibiera respuesta (cubriendo la pérdida de paquetes en UDP):

computer -> phone -> computer Pinging 192.168.1.40: 148.05968ms Pinging 192.168.1.40: 524.41156ms Pinging 192.168.1.40: 705.8688ms Pinging 192.168.1.40: 3.705367ms Pinging 192.168.1.40: 3.872159ms Pinging 192.168.1.40: 549.4541ms Pinging 192.168.1.40: 479.29843ms Pinging 192.168.1.40: 3.89936ms Pinging 192.168.1.40: 428.85876ms Pinging 192.168.1.40: 739.28125ms

He trabajado alrededor de este problema mediante el envío de paquetes de teléfono a ordenador con sólo 1 byte de datos cada 100ms, no cambiando nada en la rutina que no sea:

  computer -> phone -> computer Pinging 192.168.1.40: 4.147753ms Pinging 192.168.1.40: 3.738213ms Pinging 192.168.1.40: 14.133768ms Pinging 192.168.1.40: 4.470561ms Pinging 192.168.1.40: 3.628386ms Pinging 192.168.1.40: 3.898334ms Pinging 192.168.1.40: 3.512401ms Pinging 192.168.1.40: 7.907006ms Pinging 192.168.1.40: 5.234216ms Pinging 192.168.1.40: 5.639137ms

Es crucial que mi aplicación tenga baja latencia, así que seguiría enviando paquetes vacíos como este (al menos mientras no se transmitan datos reales). Me pregunto, si puedo forzar android a responder lo más rápido posible, sin necesidad de lanzar datos inútiles en toda la red. Entonces, ¿hay una solución más elegante?

Por cierto, estoy asumiendo que el problema es el teléfono inteligente, no la computadora, aunque también podría ser la computadora esperando paquetes entrantes y luego enviando sus paquetes. Por lo que sé acerca de redes, esto es muy poco probable, sin embargo.

¡Gracias por tu ayuda!

En lo que respecta a Java, una vez que DatagramSockect.send (…) ha sido llamado, el datagrama es "enviado". No hay almacenamiento en búfer en el espacio de aplicaciones Java, y no hay manera de controlar cualquier almacenamiento en el sistema operativo.

Es poco probable que TCP o UDP esté "reteniendo" los paquetes. Es mucho más probable que el problema raíz sea algo en el nivel WiFi … o posiblemente con enrutamiento … y el sistema operativo está retrasando el envío de los paquetes hasta que el problema se resuelva por sí mismo.

Gracias, ahora implementé el envío de esos paquetes keep-alive sólo si no hubo otro paquete enviado durante ese tiempo.

Suena como sus pings keep-alive están teniendo el efecto deseado … y de eso deduzco que el problema de raíz es / fue que el "enlace" de WiFi fue caído debido a la inactividad. (Suena como un "no drenar la batería" característica …) Esto sugiere que una solución alternativa sería ver si se puede ajustar el tiempo de espera de WiFi.

Además, ¿sería más rápido enviar paquetes a otro puerto, en el que nadie esté escuchando? Debería tener el mismo efecto sin, ¿verdad?

Es poco probable que haga ninguna diferencia. No hay evidencia de que el problema sea causado por congestión. La evidencia apunta a que su teléfono apaga el WiFi inactivo para ahorrar energía …