On Tue, Aug 26, 2008 at 04:53:59PM -0300, Leandro Lucarella wrote: > Herr Groucho, el 26 de agosto a las 16:30 me escribiste: > > > No. Para qué querés tener 10001 procesos si con uno alcanza y > > > sobre. > > > > Porque no quiero tener un arreglo de 10000 file descriptors, no sé si > > select() o poll() pueden monitorear tal cantidad de file descriptors > > (creo que no), y porque estaba bueno escribir el código del protocolo > > de comunicación en forma secuencial (te mando esto, me duerno hasta > > que contestes. Me fijo que contestaste, te respondo tal cosa y me > > duermo de nuevo, etc.) en lugar de por eventos y estados (en el > > socket 2182 ya mandé la preguta, en el 5748 todavía no. Ok, la mando > > y me acuerdo de que ya la mandé. Vino un paquete. En qué socket? El > > 9023. Ah, en ese ya había mandado la pregunta, e iba por el segundo > > intento. Ahora funcionó? Sí, bien. Va la siguiente pregunta y vuelvo > > a 0 la cuenta de reintentos y me acuerdo que voy por la segunda > > pregunta, etc.). > > Pensé que no tenías que enviar respuestas, que solamente recolectabas > datos, en cuyo caso este modelo es trivial. Si necesitás tener un > "protocolo", generalmente lo más conveniente es tener una máquina de > estados por cada socket para no perder la cabeza con la secuencialidad > (como bien decís). > > > > > - El sistema operativo soportará 10000 procesos (hace unos años > > > > el tamaño de la tabla de procesos era elegido en tiempo de > > > > compilación del kernel, en valores miserables como 200)? > > > > > > No los necesitás. > > > > Vos me estás planteando que tenga 10000 instancias independientes del > > protocolo de aplicación (o bueno, las que yo quiera, no necesito > > hablar a la vez por todos los sockets) y atienda todo en un programa > > de un solo thread > > Sí (si por "instancia del protocolo" te referís a la máquina de estados > que te decía yo para saber en que anda cada conexión y poder obrar acorde > cada vez que recibís un evento). > > > , o en un programa con un thread independiente para > > cada instancia del protocolo de comunicación? > > No, un solo thread. > > > > > - El stack TCP/IP soportará 10000 conexiones? > > > Sí > > > > > > > - Qué le pasará al consumo de memoria? > > > Bah... no debería ser muy alto. > > > > En qué caso? Cada proceso hijo recibiría un stack propio... y el > > consumo de memoria se iría a la mierda. > > Pensé que hablabas del consumo de memoria del stack TCP/IP (en cuyo caso > da lo mismo que modelo uses). > > Para el modelo que te propongo yo (un solo thread), si te sirve de algo, > te comento que mi ejemplo en Python estaba consumiendo 5MB de memoria, > a eso restale que es Python (el intérprete solo consume 2.5MB) y sumale > lo que ocupe cada maquinita de estados multiplicado por la cantidad de > sockets :) > > > > > - Qué le pasará al multitasking si el scheduler tiene que mirar > > > > una tabla de procesos tan grande cada unas pocas decenas de > > > > milisegundos? > > > > > > No debería pasar nada grave con un scheduler O(1) como el de Linux, > > > pero los context switches probablemente sí consuman mucho más > > > procesador del que quisieras. > > > > Cómo que O(1)? Es constante el tiempo? Qué mierda hace para que sea > > constante el tiempo? > > No sé los detalles, pero siempre podés mirar el código fuente =) > > Si te da miedo, podés leer algún artículo como este: > http://www.hpl.hp.com/research/linux/kernel/o1.php > > > > > Qué otras estrategias son concebibles? > > > 1 solo proceso, un solo thread + epoll[1] (o más simple, > > > libevent[2] o libev[3]). > > > > Bibliotecas de alto nivel que no conocía. Bien! > > Te hacen la vida muy simple para estas cosas. > > > > No creo que tener threads te beneficie en algo, a menos que tengas > > > más de un core, por supuesto. > > > > Me beneficia en el razopnamiento del problema. Cada comunicación es > > independiente y secuencial. Es mentalmente mucho más simple de > > modelar la situación con threads que con eventos. Ver más arriba cómo > > luce la implementación del protocolo con threads/procesos > > independientes y con eventos. > > Te entiendo, pero si usás máquinas de estado se vuelve reeee manejable.
Yo no estoy tan de acuerdo aca. Salvo que tengas algo muy complejo, termina siendo mas facil. Hace un tiempo arme algo similar a lo que Groucho plantea con libevent y se muy facil. Es cuestion de cambiar un poco la mente :) > > > > Anda bien con los 10000 sockets, usando poll (NO epoll) y en un > > > lenguaje interpretado. En mi Athlon XP 2200 (1.8GHz) está el CPU > > > entre 80% y 85% y el load average entre 2 y 8 (con el X abierto con > > > varias aplicaciones, incluido el puto Firefox que está usando 8% > > > del CPU vaya uno a saber en qué). Les puse que mande un mensaje > > > cada 10ms y completa una "ronda" de los 10000 fds en unos 2 > > > minutos. > > > > > > Como verás, lo tuyo es un no-problema... > > > > Caramba. El C10K problem es un no-problem... Sos groso, sabelo. > > Lo sé, pero más grosos son los que hicieron las cosas que te pasé =P > > > Y gracias por los datos. > > De nada. > > -- > Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ > ---------------------------------------------------------------------------- > GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) > ---------------------------------------------------------------------------- > Never let a fool kiss you, or let a kiss fool you -- -------------- Diego Woitasen
