[pyar] [OT] Arquitectura + Sockets!

[Santiago Basulto]

Se puso interesante la charla.

La verdad no tengo mucha experiencia con C ni C++. Si fuera Java o
Scala te recomendaría Akka de cabeza (si no me creen, lean esto:
http://letitcrash.com/post/17607272336/scalability-of-fork-join-pool)
;).

Creo que depende mucho de la utilización. Si vas a hacer un protocolo
muy general o algo puntual para un caso específico, si vas a tener
demasiada IO, etc.. De qué sería el servidor?

Acá está la implementación de libzmq, que es el core de ZeroMQ:
https://github.com/zeromq/libzmq

Puede ser un buen punto de partida para chusmear la implementación y
la arquitectura.

Saludos!

El día 26 de junio de 2012 16:11, Angel Java Lopez
<ajlopez2000 en gmail.com> escribió:
> Y cuando hay que debuggear un thread?
>
> Sospecho que depende de la implementacion de base. Yo por anios, en
> servidores Java y .NET, nunca tuve problemas con los threads. Eran
> servidores principalmente web, pero cuya infraestructura arma, dentro de un
> pool de thread, todo lo que necesita mi thread worker, sin mezclar los
> tantos con los otros threads.
>
> Asi que si tu servidor toma ese camino: rapidamente, ante cada cliente, arma
> todo lo necesario, y que los demas clientes/threads no se enteren de eso, no
> deberia (no digo que se expulsa todo, pero no deberia) en general haber
> problema.
>
> Pero depende de que es tu servidor. Si es un servidor web, donde cada
> cliente "no ve al otro", no deberia haber mayor problema. Si es un servidor
> de chat, o de juegos multiplayer, deberia controlarse los accesos a partes
> comunes. Si en este ultimo caso, no usas threads, sino procesos separados,
> como coordinar? con InterProcess Communication? Shared Memory? Un redis en
> otro lado? No se, me parece que son mas complejos de resolver problemas en
> esas configuraciones/soluciones.
>
> Comentarios? otras opiniones, contextos?
>
> Cual es el tipo de servidor que tenes que armar? cliente que no conoce a
> otro cliente? o hay alguna interaccion entre ellos?
>
> 2012/6/26 Martin Alderete <malderete en gmail.com>
>>
>> 2012/6/26 Alejandro J. Cura <alecu en protocultura.net>
>>>
>>> 2012/6/26 Martin Alderete <malderete en gmail.com>:
>>> >
>>> >
>>> > 2012/6/26 Alejandro J. Cura <alecu en protocultura.net>
>>> >>
>>> >> 2012/6/26 Martin Alderete <malderete en gmail.com>:
>>> >> > 2012/6/26 Alejandro J. Cura <alecu en protocultura.net>
>>> >> >
>>> >> >> 2012/6/26 Martin Alderete <malderete en gmail.com>:
>>> >> >> > Buenas gente!
>>> >> >> > Como estan?
>>> >> >> >
>>> >> >> > Esta pregunta es off-topic y no es python related...
>>> >> >> >
>>> >> >> > Basicamente para la facultad  tengo que escribir un server en C
>>> >> >> > que
>>> >> >> > le
>>> >> >> > de
>>> >> >> > contenido a los clientes usando un protocolo creado por mi.
>>> >> >> > Como tengo tiempo para realizarlo estoy evaluando arquitecturas
>>> >> >> > para
>>> >> >> > ver
>>> >> >> > los
>>> >> >> > drawbacks de cada una...
>>> >> >> >
>>> >> >> > Que me recomiendan para que el server escale con varios clientes?
>>> >> >>
>>> >> >> Cuantos clientes? diez, cien o diezmil?
>>> >> >
>>> >> >
>>> >> >
>>> >> >  Me gustaria rondar los 50 clientes
>>> >>
>>> >> Entonces no vas a tener problemas de performance con ninguna de esas
>>> >> opciones.
>>> >> Lo podés hacer forkeando por cada conexión que va a andar rápido.
>>> >
>>> >
>>> > Gracias Ale! Y si lo quiero escalar a 1000 o mas... que recomendas?
>>> > Analizando que fork es "costoso" para el SO...
>>
>>
>> Angel, gracias por tu respuesta!! Si esa clase de arquitecturas las estuve
>> evaluando y ya he hecho algunos desarrollos con eso :)... el pool de threads
>> era una opcion
>>
>>>
>>> El link obligatorio, (aunque ya tiene 13 añitos lo siguen
>>> actualizando): http://www.kegel.com/c10k.html
>>
>>
>> Sip, a ese articulo lo  lei =D!
>>
>>> A mi me gustan las soluciones asincrónicas como select o epoll. Por
>>> eso me gusta tanto twisted :-)
>>
>>
>> A mi tambien me gustan las soluciones asincronicas, pero la pregunta si se
>> ajusta a este problema ese esquema.
>>
>>>
>>> Usar threads para esto puede ser más fácil de arrancar, pero es común
>>> llegar a un punto imposible de debuguear.
>>
>>
>> Sip, ese es mi miedo... debuguear thread ==  MAL_DE_CABEZA xD
>>
>>
>> saludos
>>
>> --
>> Alderete, Martin Nicolas
>>
>>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar



-- 
Santiago Basulto.-