Metodo para comunicar instancias de objetos

[Jesus Cea]

-----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-----
------------ próxima parte ------------
_______________________________________________
Python-es mailing list
Python-es en aditel.org
http://listas.aditel.org/listinfo/python-es