¿Qué ocurre con TCP y UDP (con multidifusión) de conexión cuando una aplicación iOS hizo entrar en el fondo

Question

creé par de experimentos:

Configuración 1: He creado una aplicación TCP remitente y una aplicación TCP Receptor.

Para este experimento, que comenzó el emisor TCP en un dispositivo iOS y el receptor TCP en otro dispositivo iOS. Y luego se verifica que ambos hicieron conexión y enviaron y recibieron datos. Luego pongo la aplicación TCP Receiver en segundo plano. La aplicación TCP Sender indicó que se perdió la conexión y se colgó (sí, así lo hice).

Configuración 2: He creado una aplicación remitente UDP y una aplicación de receptor UDP.

Igual que el anterior, que comenzó la aplicación del remitente UDP en un dispositivo iOS y la aplicación del receptor UDP en otro dispositivo iOS. En la aplicación UDP Receiver me suscribí a un grupo de multidifusión, etc. Comprobé que la aplicación UDP Receiver está recibiendo los datos de ese grupo de multidifusión enviado por la aplicación UDP Sender. Luego coloco la aplicación UDP Receiver en segundo plano. Después de 2 minutos, obtengo la aplicación UDP Sender para enviar otro dato. Luego salgo de la aplicación UDP Sender por completo y apago el dispositivo iOS. Luego espero otros 2 minutos o más, y luego abro la aplicación UDP Receiver desde el fondo. La aplicación UDP Receiver recibió los datos enviados por la aplicación UDP Sender antes de que finalizara.

En setup1, mi explicación es porque TCP está orientado a la conexión.

En setup2, entiendo que UDP no tiene conexión. ¿Alguna explicación de por qué setup2 funcionó en mi experiencia? (Todavía recibe datos incluso en modo de fondo)

Answer 1

Todo lo que sucede cuando pones una aplicación en segundo plano y la dejas suspendida es que deja de ser programada por el kernel. No interrumpe inmediatamente ninguna conexión ni desconecta ningún zócalo (a menos que lo fuerce).

En su caso UDP, el kernel recibe el paquete y lo coloca en un buffer del kernel, esperando que su aplicación lo reciba . Como el proceso de su aplicación existe, pero se detiene de manera efectiva, los datos simplemente se ubicarán en el búfer del kernel. Si obtienes demasiados datos, rebasarán el buffer del núcleo y se descartarán. De lo contrario, su aplicación puede recibirla cuando (si) está programada de nuevo.

En el caso de TCP, más o menos lo mismo sucede.

Pero (pero grande): el sistema operativo siempre tiene la opción de desconectar los enchufes de las aplicaciones suspendidas si lo desea, en función de la presión de la memoria, etc. Por lo tanto, aunque no necesariamente lo haga de forma gratuita, puede hacerlo .

No estoy seguro de por qué está viendo la conexión TCP cortada rápidamente. Es posible que la heurística del núcleo para el servidor de las conexiones TCP sea más agresiva que para los sockets UDP ya que las conexiones TCP requieren más estado y más procesamiento continuo que los sockets UDP.

Ver Technical Note TN2277 Networking and Multitasking.

Answer 2

Mi opinión es por el sistema operativo, esto no debería estar sucediendo si probó con un sistema operativo Android porque IO tiene restricciones sobre qué puede funcionar en segundo plano y qué no.

Por lo que dices creo que es porque TCP requiere más recursos para enviar información. TCP usa flujos de datos y UDP usa bloques de datos. El problema es que TCP crea paquetes de datos más grandes mientras que UDP usa 8 kb de bloques de datos.