Metodo para comunicar instancias de objetos

[Pau Freixes]

Buena Jesus

He estado echando una ojeada a spread, y tus comentarios al respeto en
la lista de pyro par implementar la tecnología "inside" de la propia
metodología de trabajo de pyro ....

Primero de todo pensé que spread era un sistema transparente, o sea era
aplicable a cualquier proceso que fuera suceptible a "doblar" y que
estuviera escuchando un puerto, y que el programa no necessitaba de ser
modificado para realizar esto, pero veo que no.

Pero bueno, como nosotros trabajamos des de 0 y con codigo en python no
nos importa realizar cambios que mejoren la calidad del proyecto, y si
esto quiere decir implementar spread como capa en background pues
beinvenido sea

El único problema que veo, es donde implementarlo, cada cual tiene sus
ventajas

1) Debajo de los NameServers. implica no cambiar el codigo de los
servers ni su metodologia pero tenemos que replicar tantos NameSpaces
como ordenadores tenemos y no detectamos la caida de servers - fallo en
la programación, exepcion no controlada ... - solo la caida del
ordenador o el NameServers. Tiene muy poco impacto sobre la arquitectura
de pyro

2) En Medio, cambiar la politica actual de servidores. Como ya comentas
lo mejor seria tener los servidores que fueran ellos mismos los que
resolvieran los requests sobre peticion de objetos y que el NameServer
desapareciera .... el impacto es alto, hay que modificar sustancialmente
la política de pyro  - un fork amigable :) .

Donde te encuentras tu ? 

On dt, 2006-03-28 at 14:34 +0200, Jesus Cea wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Pau Freixes wrote:
> >> Por supuesto. En el servidor de nombres pyto puedes dar de alta varios
> >> objetos equivalentes, y el cliente se conecta al azar a uno de ellos,
> >> cuando necesita sus servicios
> > 
> > Bueno y para terminar la serie de pyro, que passa con el balanceo si uno
> > de los dos servidores - por ejemplo - que mantenia un registro de un
> > objeto cae ? El NameServer se da cuenta de forma asíncrona ? aplica una
> > politica fault tolerance en vez de round robin y elimina la entrada de
> > ese server.objeto ?
> 
> El cliente recibe varias entradas desde el nameserver, tantas como
> objetos registrados haya. Si intenta conectar con un objeto que no está
> funcionando, tu aplicación debe detectarlo e intentar el objeto siguiente.
> 
> No, el nameserver no se entera de que han desaparecido objetos. El
> destructor de un objeto se encarga de darlo de baja en el "nameserver",
> pero si la máquina se resetea, por ejemplo, nadie da de baja nada.
> 
> A mí tampoco me gusta eso. Por eso hace mucho hice una propuesta en la
> lista de Pyro, pero parece que a nadie le interesó el asunto. Se basaba
> en eliminar el servidor de nombres y utilizar en cambio "spread" como
> sistema 100% distribuido, en el que cada objeto era responsable de su
> propia resolución ante terceros.
> 
> Lamentablemente la lista de correo de pyro parece no tener los archivos
> online.
> 
> Buscaré en my carpeta "send" y lo colgaré de mi web. Mandaré URL cuando
> lo haya hecho.
> 
> Vaya, parece que los archivos sí están online, pero google no los
> indexa. Los tienes en
> <http://sourceforge.net/search/?type_of_search=mlists&forum_id=8351&group_id=18837&atid=0&words=spread&Search=Search>
> 
> Los mensajes más relevantes son:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=10599140
> http://sourceforge.net/mailarchive/message.php?msg_id=11142919
> http://sourceforge.net/mailarchive/message.php?msg_id=10586676
> http://sourceforge.net/mailarchive/message.php?msg_id=10583679
> 
> No meneé el tema porque llevo años usando un esquema similar en mi
> propia red, con excelentes resultados, y cuando toqué el tema en la
> lista o la peña estaba muy despistada o no interesó a nadie...
> 
> Es algo que se puede retomar, si hay interés suficiente. La verdad es
> que el asunto es bastante sencillito, y soluciona un problema grave. La
> única desventaja es que requiere SPREAD por debajo, que es una
> tecnología bastante truculenta. Pero como yo ya uso spread para más
> proyectos, mi coste marginal es cero :-)
> 
> Me pasa lo mismo con mi proyecto "durus-berkeleydbstorage", que requeire
> BerkeleyDB por debajo. Para utilizar BerkeleyDB como dios manda y sin
> sustos hay que dominarla bastante, pero como yo ya la uso en multitud de
> otros proyectos, ese coste ya no lo tengo.
> 
> - --
> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> jcea en argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
> jabber / xmpp:jcea en jabber.org         _/_/    _/_/          _/_/_/_/_/
>                                _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iQCVAwUBRCktSJlgi5GaxT1NAQIRNgQAkSpIcpT8aQheiJCt1/jwyc38Dzy4DGwB
> aezF9yBoxGqwniPv93ydANghSEs8YqSHdBfpLikuatKfJOLJ1p8TnJfvMQ7z38kM
> 6rXIVqxlVif8H1lKALgbzlHyldFtAT45DcZ0ufVJqK+FpeGLjW9D1D9qfZUk29WK
> kPShfVJtUi8=
> =LSon
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es