Just so I understand the process, why not just use JavaGroups:
http://www.cs.cornell.edu/Info/Projects/JavaGroupsNew/
http://www.sourceforge.net/projects/javagroups
it has both process groups and Bimodal Multicast (Probabilistic Broadcast),
an active set of users, and an optional high performance network
layer.
RME
[EMAIL PROTECTED] wrote:
> Feature Requests item #454626, was opened at 2001-08-23 09:27
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=376688&aid=454626&group_id=22866
>
> Category: None
> Group: None
> Status: Open
> Priority: 5
> Submitted By: Nobody/Anonymous (nobody)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: replicated cluster
>
> Initial Comment:
> I have written a Java implementation of the TOTEM
> protocol, as published by a research group at UCSB.
> The protocol has several features:
>
> 1. Messages are multicast, rather than sent point-to-
> point, leading to good scalability with respect to the
> number of receivers.
>
> 2. It is reliable. Endpoints in the protocol form a
> group, and the protocol enforces that either all
> members of the group receive a message, or the members
> that did all failed. Retransmission of dropped
> messages is done using NAKs rather than ACKs.
>
> 3. All members of a group deliver the messages to the
> application in the same order. This (a.k.a. total
> ordering) is implemented using a rotating token.
>
> 4. It has an effective flow control algorithm. The
> flow control information is piggybacked on the token.
> Because on small LANs most messages are lost because
> of buffer overflow, flow control is the determining
> factor in the ultimate performance of the protocol.
> Basically it works so well that hardly any messages
> are ever dropped.
>
> 5. The last feature is my own humble contribution to
> this protocol. Because the flow control put in by UCSB
> requires a window size to be tuned by hand, I put in a
> form of congestion avoidance and control algorithm
> that dynamically tunes the window size. So no tuning
> is needed. The algorithm is based on the CAC algorithm
> used in TCP.
>
> I implemented this in Java after spending months
> researching how to best use multicasting to write a
> coherent cache for a job I was doing. On my 455Mhz
> pIII it performs at about 4000 1kb messages per
> second. I was going to build other things on top of
> it, like a replicated EJB server, but the fun part was
> the protocol, and I have kind of lost interest.
> However, you already have an EJB server. If you can
> see how to use this protocol to your advantage, and
> you have someone to devote to working on this, I am
> interested in talking to you.
>
> Best regards,
> Guglielmo
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=376688&aid=454626&group_id=22866
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
