The nice thing about it is that there are no ACKS/NACKS so, it's not
very chatty. The bad thing is that you have to wait for the token to
come your way before you can broadcast; if there are a lot of
participants in the group the latency will be larger that you might like.
http://citeseer.csail.mit.edu/amir95totem.html
Regards,
Alan
Jeff Genender wrote, On 1/12/2006 2:53 PM:
Guglielmo,
Ok..lets chat about the technical components of Totem. What are the
strengths and weaknesses? Is there scaling issues, and if so, are there
some mitigation strategies from an algorithm perspective?
Feel free to elaborate...this is great stuff.
Thanks,
Jeff
[EMAIL PROTECTED] wrote:
Yes...awesome. Bruce had chatted with me about this too...I am very
interested.
Thanks.
Guglielmo, I would be very interested in speaking with you further on
this.
I am available to speak more about it. If you need my phone number, it's
six one nine, two five five, nine seven eight six.
This is looks like something we could heavily use. What's your thoughts?
I think totem is a great protocol. Whether _you_ need it depends on the
application. I originally wrote this code back in 2000, and it took me
this long to find the ideal application for it.
I would like to recommend the following article by Ken Birman (probably
the grandad of process groups):
http://portal.acm.org/citation.cfm?id=326136
Unfortunately you need to be a member of the acm to read it (I used to be,
but right now I am not.) This article describes his experiences using
ISIS, an early process group library, to build some interesting systems.
Guglielmo
