All Packages from org.jgroups.protocols.pbcast.* to org.jgroups.protocols.ring.*

Home >> All >> org >> jgroups >> [ protocols Javadoc ]

•

• org.jgroups.protocols: Javadoc index of package org.jgroups.protocols.

Package Samples:

• org.jgroups.protocols.pbcast: Provides implementations of transport protocols which are responsible for sending and receiving messages to/from the network.
• org.jgroups.protocols.ring: Provides implementations of transport protocols which are responsible for sending and receiving messages to/from the network.

Classes:

• ENCRYPT: ENCRYPT layer. Encrypt and decrypt the group communication in JGroups The file can be used in two ways: Option 1. Configured with a secretKey in a keystore so it can be used at any layer in JGroups without the need for a coordinator, or if you want protection against passive monitoring but do not want the key exchange overhead and complexity. In this mode all nodes must be distributed with the same keystore file. Option 2. Configured with algorithms and key sizes. The Encrypt Layer in this mode sould be used between the FRAG and PBCast layers in the stack. The coordinator then chooses the secretkey ...
• NAKACK: Negative AcKnowledgement layer (NAKs), paired with positive ACKs. The default is to send a message using NAKs: the sender sends messages with monotonically increasing seqnos, receiver requests retransmissions of missing messages (gaps). When a SWITCH_NAK_ACK event is received, the mode is switched to using NAK_ACKS: the sender still uses monotonically increasing seqnos, but the receiver acknowledges every message. NAK and NAK_ACK seqnos are the same, when switching the mode, the current seqno is reused. Both NAK and NAK_ACK messages use the current view ID in which the message is sent to queue ...
• CAUSAL: Implements casual ordering layer using vector clocks. Causal protocol layer guarantees that if message m0 multicasted by a process group member p0 causes process group member p1 to multicast message p1 then all other remaining process group members in a current view will receive messages in order m0 followed by m1. First time encountered, causal order seems very similar to FIFO order but there is an important distinction. While FIFO order gurantees that if process group member p0 multicasts m0 followed by m1 the messages will be delivered in order m0,m1 to all other group members, causal order ...
• TOTAL: Implements the total ordering layer using a message sequencer The protocol guarantees that all bcast sent messages will be delivered in the same order to all members. For that it uses a sequencer which assignes monotonically increasing sequence ID to broadcasts. Then all group members deliver the bcasts in ascending sequence ID order. When a bcast message comes down to this layer, it is placed in the pending down queue. A bcast request is sent to the sequencer. When the sequencer receives a bcast request, it creates a bcast reply message and assigns to it a monotonically increasing seqID and sends ...
• UDP_NIO: Multicast transport. Similar to UDP, but binds to multiple (or all) interfaces for sending and receiving multicast and unicast traffic. The list of interfaces can be set via a property (comma-delimited list of IP addresses or "all" for all interfaces). Note that this class only works under JDK 1.4 and higher. For each of the interfaces listed we create a Listener, which listens on the group multicast address and creates a unicast datagram socket. The address of this member is determined at startup time, and is the host name plus a timestamp (LogicalAddress). It does not change during the lifetime ...
• TP: Generic transport - specific implementations should extend this abstract class. Features which are provided to the subclasses include version checking marshalling and unmarshalling message bundling (handling single messages, and message lists) incoming packet handler loopback A subclass has to override sendToAllMembers(byte[], int, int) 55 sendToSingleMember(org.jgroups.Address, byte[], int, int) 55 Protocol.init() > Protocol.init() 55 start() 55 : subclasses must call super.start() after they initialize themselves (e.g., created their sockets). stop() 55 : subclasses must call super.stop() after ...
• FLUSH: The task of the FLUSH protocol is to flush all pending messages out of the system. This is done before a view change by stopping all senders and then agreeing on what messages should be delivered in the current view (before switching to the new view). A coordinator broadcasts a FLUSH message. The message contains an array of the highest sequence number for each member as seen by the coordinator so far. Each member responds with its highest sequence numbers seen so far (for each member): if its sequence number for a member P is higher than the one sent by the coordinator, it will append the messages ...
• STABLE: Computes the broadcast messages that are stable; i.e., that have been received by all members. Sends STABLE events up the stack when this is the case. Uses a probabilistic scheme to do so, as described in: GSGC: An Efficient Gossip-Style Garbage Collection Scheme for Scalable Reliable Multicast, K. Guo et al., 1997. The only difference is that instead of using counters for an estimation of messages received from each member, we retrieve this actual information from the NAKACK layer (which must be present for the STABLE protocol to work). Note: the the Event.MSG call path path must be as lightweight ...
• FD_PID: Process-ID based FD protocol. The existence of a process will be tested via the process ID instead of message based pinging. In order to probe a process' existence, the application (or some other protocol layer) has to send down a SET_PID event for the member. The addresses of all members will be associated with their respective PIDs. The PID will be used to probe for the existence of that process. A cache of Addresses and PIDs is maintained in each member, which is adjusted upon reception of view changes. The population of the addr:pid cache is as follows: When a new member joins, it requests ...
• UNICAST: Reliable unicast layer. Uses acknowledgement scheme similar to TCP to provide lossless transmission of unicast messages (for reliable multicast see NAKACK layer). When a message is sent to a peer for the first time, we add the pair to the hashtable (peer address is the key). All messages sent to that peer will be added to hashtable.peer_addr.sent_msgs. When we receive a message from a peer for the first time, another entry will be created and added to the hashtable (unless already existing). Msgs will then be added to hashtable.peer_addr.received_msgs. This layer is used to reliably transmit point-to-point ...
• SMACK: Simple Multicast ACK protocol. A positive acknowledgment-based protocol for reliable delivery of multicast messages, which does not need any group membership service. Basically works as follows: Sender S sends multicast message M When member P receives M, it sends back a unicast ack to S When S receives the ack from P, it checks whether P is in its membership list. If not, P will be added. This is necessary to retransmit the next message sent to P. When S sends a multicast message M, all members are added to a retransmission entry (containing all members to which the message was sent), which is ...
• JMS: Implementation of the transport protocol using the Java Message Service (JMS). This implementation depends on the JMS server that will distribute messages published to the specific topic to all topic subscribers. Protocol parameters are: topicName - (required), full JNDI name of the topic to be used for message publishing; cf - (optional), full JNDI name of the topic connection factory that will create topic connection, default value is "ConnectionFactory" ; jndiCtx - (optional), value of the javax.naming.Context.INITIAL_CONTEXT_FACTORY property; you can specify it as the JVM system property -Djava.naming.factory.initial=factory.class.Name ...
• NAKACK: Negative AcKnowledgement layer (NAKs). Messages are assigned a monotonically increasing sequence number (seqno). Receivers deliver messages ordered according to seqno and request retransmission of missing messages. Retransmitted messages are bundled into bigger ones, e.g. when getting an xmit request for messages 1-10, instead of sending 10 unicast messages, we bundle all 10 messages into 1 and send it. However, since this protocol typically sits below FRAG, we cannot count on FRAG to fragement/defragment the (possibly) large message into smaller ones. Therefore we only bundle messages up to max_xmit_size ...
• FD_SOCK: Failure detection protocol based on sockets. Failure detection is ring-based. Each member creates a server socket and announces its address together with the server socket's address in a multicast. A pinger thread will be started when the membership goes above 1 and will be stopped when it drops below 2. The pinger thread connects to its neighbor on the right and waits until the socket is closed. When the socket is closed by the monitored peer in an abnormal fashion (IOException), the neighbor will be suspected. The main feature of this protocol is that no ping messages need to be exchanged between ...
• PERF: Measures time taken by each protocol to process a message. PERF has to be the top protocol in a stack. It adds a special header to the message which travels with the message. Upon initialization, PERF creates a ProtocolObserver for each protocol layer in the stack. That observer notes the time taken for a message to travel through the layer it observes, and records the start time, end time and total time in the message itself (in the header created by PERF). When a message is received by PERF, the statistics for the message are appended to a file (or displayed in a GUI (not yet done)). Because ...
• MERGE2: Protocol to discover subgroups; e.g., existing due to a network partition (that healed). Example: group {p,q,r,s,t,u,v,w} is split into 3 subgroups {p,q}, {r,s,t,u} and {v,w}. This protocol will eventually send a MERGE event with the coordinators of each subgroup up the stack: {p,r,v}. Note that - depending on the time of subgroup discovery - there could also be 2 MERGE events, which first join 2 of the subgroups, and then the resulting group to the last subgroup. The real work of merging the subgroups into one larger group is done somewhere above this protocol (typically in the GMS protocol). ...
• UDP: IP multicast transport based on UDP. Messages to the group (msg.dest == null) will be multicast (to all group members), whereas point-to-point messages (msg.dest != null) will be unicast to a single member. Uses a multicast and a unicast socket. The following properties are read by the UDP protocol: param mcast_addr - the multicast address to use; default is 228.8.8.8. param mcast_port - (int) the port that the multicast is sent on; default is 7600 param ip_mcast - (boolean) flag whether to use IP multicast; default is true. param ip_ttl - the default time-to-live for multicast packets sent out ...
• STABLE: Computes the broadcast messages that are stable; i.e., have been received by all members. Sends STABLE events up the stack when this is the case. This allows NAKACK to garbage collect messages that have been seen by all members. Works as follows: periodically we mcast our highest seqnos (seen for each member) to the group. A stability vector, which maintains the highest seqno for each member and initially contains no data, is updated when such a message is received. The entry for a member P is computed set to min(entry[P], digest[P]). When messages from all members have been received, a stability ...
• FD: Failure detection based on simple heartbeat protocol. Regularly polls members for liveness. Multicasts SUSPECT messages when a member is not reachable. The simple algorithms works as follows: the membership is known and ordered. Each HB protocol periodically sends an 'are-you-alive' message to its *neighbor*. A neighbor is the next in rank in the membership list, which is recomputed upon a view change. When a response hasn't been received for n milliseconds and m tries, the corresponding member is suspected (and eventually excluded if faulty). FD starts when it detects (in a view change notification) ...
• FLOW_CONTROL: FLOW_CONTROL provides end-end congestion control and flow control. Attempts to maximize through put, by minimizing the possible block times(Forward flow control). Initially, sender starts with a smaller window size W and large expected RTT grpRTT . Sender also keeps a margin in the window size. When the margin is hit, insted of waiting for the window size to be exhausted, sender multicasts a FLOW_CONTROL info request message. If the window size is exhausted before the responses are received, send will be blocked. FCInfo(flow control info) from all the receivers is gathered at the sender, and current ...
• Discovery: The Discovery protocol layer retrieves the initial membership (used by the GMS when started by sending event FIND_INITIAL_MBRS down the stack). We do this by specific subclasses, e.g. by mcasting PING requests to an IP MCAST address or, if gossiping is enabled, by contacting the GossipServer. The responses should allow us to determine the coordinator whom we have to contact, e.g. in case we want to join the group. When we are a server (after having received the BECOME_SERVER event), we'll respond to PING requests with a PING response. The FIND_INITIAL_MBRS event will eventually be answered with ...
• FRAG2: Fragmentation layer. Fragments messages larger than frag_size into smaller packets. Reassembles fragmented packets into bigger ones. The fragmentation number is prepended to the messages as a header (and removed at the receiving side). Each fragment is identified by (a) the sender (part of the message to which the header is appended), (b) the fragmentation ID (which is unique per FRAG2 layer (monotonically increasing) and (c) the fragement ID which ranges from 0 to number_of_fragments-1. Requirement: lossless delivery (e.g. NAK, ACK). No requirement on ordering. Works for both unicast and multicast ...
• Digest: A message digest, which is used by the PBCAST layer for gossiping (also used by NAKACK for keeping track of current seqnos for all members). It contains pairs of senders and a range of seqnos (low and high), where each sender is associated with its highest and lowest seqnos seen so far. That is, the lowest seqno which was not yet garbage-collected and the highest that was seen so far and is deliverable (or was already delivered) to the application. A range of [0 - 0] means no messages have been received yet. April 3 2001 (bela): Added high_seqnos_seen member. It is used to disseminate information ...
• TOTAL_TOKEN: Total order implementation based on The Totem Single-Ring Ordering and Membership Protocol . However, this is an adaption of algorithm mentioned in the research paper above since we reuse our own membership protocol and failure detectors. Somewhat different flow control mechanism is also implemented. Token passing is done through reliable point-to-point udp channels provided by UNICAST layer. Process groups nodes members are organized in a logical ring. Total token layer doesn't need NAKACK nor STABLE layer beneath it since it implements it's own retransmission and tracks stability of the messages ...
• TCPPING: The TCPPING protocol layer retrieves the initial membership in answer to the GMS's FIND_INITIAL_MBRS event. The initial membership is retrieved by directly contacting other group members, sending point-to-point mebership requests. The responses should allow us to determine the coordinator whom we have to contact in case we want to join the group. When we are a server (after having received the BECOME_SERVER event), we'll respond to TCPPING requests with a TCPPING response. The FIND_INITIAL_MBRS event will eventually be answered with a FIND_INITIAL_MBRS_OK event up the stack. The TCPPING protocol ...

Home | Contact Us | Privacy Policy | Terms of Service