-
Notifications
You must be signed in to change notification settings - Fork 3
Communication Protocol Design
sixtam edited this page Oct 30, 2012
·
2 revisions
This page should describe main ideas behind the new BEEN communication protocol as well as document our work and progress.
The result of our work should be protocol which would enable the BEEN framework to communicate asynchronously and reliably. The change from synchronous (RMI) to asynchronous middleware has deep implications.
- even-based/message driven system
Several technologies were considered
-
- point to point
-
- publish/subscribe
-
- single point of failure (broker)
-
- clustering
-
- clustering
-
- p2p architecture, no single point of failure
-
- implementation of distributed data structures
-
- very easy to use
-
- transactions (JCA)
-
- persistence
-
- publish/subscribe
-
- TCP (there are about 225 TCP connections for 40 nodes on localhost, how does this scale with thousands of nodes)
Maybe we should look at JGroups. It's focus is on distributed communication (reliable multicast) as opposed to Hazelcast which is rather focused on distributed data. Nevertheless it seems to me that Hazelcast can do most things as JGroups and some more. However JGroups can use UDP as the transport protocol
-
- channels (group membership)
-
- fine tuning
-
- UDP, TCP or JMS as the transport protocol
We are currently evaluating Hazelcast as the main communication middleware