Barrapunto

Mmmh, la solucion que propones no termina de convencerme. Veras, con 2 contadores, uno de tiempo y otro de usuarios, hay varios escenarios.

• Si esperas a que el contador de usuarios llegue a determinado numero y empiezas a retransmitir, y, en un periodo corto de tiempo, se llena el cupo de clientes, tendras que hacer 2 retransmisiones. Esperando ese periodo de tiempo, te ahorrarias una. La idea esta bien si se ajusta dinamicamente el numero de clientes, no es aceptable tener 1 hora esperando a un cliente porque quiere ver un programa cuando el resto del mundo duerme, y no es rentable para ti, hacer 100 retransmisiones simultaneas, si tienes el cupo de clientes demasiado bajo (10 por ejemplo) y recibes 1000 peticiones en 5 minutos.
• Que un cliente haga una peticion, y sea la unica persona que quiere ver eso en ese momento. Tiene que esperar a que venza el "timeout" para ver el programa, y tu vas a gastar el mismo ancho de banda esperando a que venza que sin esperar. El cliente pierde tiempo y tu te quedas exactamente igual.

O sea, que o ajustas estaticamente muy bien el numero de usuarios, y aun asi en momentos tu servicio no va a ir todo lo bien que pudiera, o lo haces dinamicamente (seguramente esta seria la forma optima y tu solucion hibrida sea la mejor), o lo limitas a un tiempo razonable y asi vas a tener un consumo de ancho de banda mas plano, sin picos (ancho de banda consumido por un unico programa, claro).
Resumiendo: haciendolo estaticamente si pones un numero de usuarios demasiado alto, el algoritmo desemboca en uno basado en tiempo nada mas, y si pones un numero demasiado bajo, vas a tener un numero excesivo de retransmisiones.

¿Cuando hacemos un servidor de television a la carta ranurada con deteccion dinamica de clientes minimos (TCRDDCM)?