Interesting, very interesting. How does this compare to the groups stuff we have been using so far? marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |[EMAIL PROTECTED] |Sent: Thursday, August 23, 2001 12:27 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] [ jboss-Feature Requests-454626 ] replicated |cluster | | |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
