Hola Juan, va entre líneas >>>
Entiendo por donde viene tu comentario: Tener un thread por cliente no escala, no solo por tema de recursos sino porque en promedio a cada cliente le tocaría 1/N del video (yo no había entendido esta parte). Pero tener un thread solo tiene el problema de que el último cliente de la lista va a tener un delay importante en comparación con el primero.
>>> Correcto, también podrías complicarte tratando de asegurar que el frame se envíe a todos.
Se puede asumir que el tiempo que lleva ejecutar el sendto es despreciable para el caso de UDP?
>>> A diferencia de TCP, UDP no asegura la llegada del segmento, por lo que no es descabellado pensar que el sento no demoraría los envíos.
Resumiendo, se me ocurre que la solución más simple sería tener:
* Un thread para el accept TCP, agrega algo del estilo (tcp, socket, now()) a la lista de clientes
* Un thread para aceptar requests UDP, agrega alg del estilo (udp, ip, port, now()) a la lista de clientes
* Un thread que lee frames y los envía a todos los clientes (UDP o TCP) registrados
>>> Tiene sentido. Solo agregar que el último thread deberá controlar en cada envío que la suscripción esté renovada.
Capaz que con esto se cumple con el objetivo del ejercicio pero, si quisiéramos achicar el delay, capaz que podríamos contar con un pool de M threads donde cada hilo se encarga de enviarle los frames a N/M clientes.
Vale la pena complicarse con eso para este ejercicio?
>>> No, pero es un buen ejercicio para que vean que estos problemas existen y hay que evaluar que solución nos conviene más. Como dice la letra, este ejercicio es del Obligatorio 2 del 2017, por lo que al implementar esto en un lenguaje como C se ve mejor como afectan estas desiciones.
Saludos