Given the inherent over head in total order protocols, I think we
should work to limit the messages passed over the protocol, to only
the absolute minimum to make our cluster work reliably.
Specifically, I think this is only the distributed lock. For state
replication we can use a much more efficient tcp or udp based protocol.
-dain
On Jan 12, 2006, at 3:02 PM, Alan D. Cabrera wrote:
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
