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

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


Package Samples:

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

Classes:

• 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 ...
• 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 ...
• 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 ...
• FD: Passive failure detection protocol. It assumes a pbcast protocol, which uses rounds of gossiping for reliable message delivery. Gossip protocols typically involve all the members sending gossips in regular intervals. This protocol therefore works as follows: it allocates a timestamp for each member and updates the timestamp whenever it receives a message from a sender P. Any type of message is accepted from P. For example, PBCAST regularly sends the following messages: regular mcast message from P regular ucast message from P gossip from P retransmit request from P retransmit response from P
• ClientGmsImpl: Client part of GMS. Whenever a new member wants to join a group, it starts in the CLIENT role. No multicasts to the group will be received and processed until the member has been joined and turned into a SERVER (either coordinator or participant, mostly just participant). This class only implements Join (called by clients who want to join a certain group, and ViewChange which is called by the coordinator that was contacted by this client, to tell the client what its initial membership is.
• STATE_TRANSFER: New STATE_TRANSFER protocol based on PBCAST. Compared to the one in ./protocols, it doesn't need a QUEUE layer above it. A state request is sent to a chosen member (coordinator if null). That member makes a copy D of its current digest and asks the application for a copy of its current state S. Then the member returns both S and D to the requester. The requester first sets its digest to D and then returns the state to the application.
• PBCAST: Implementation of probabilistic broadcast. Sends group messages via unreliable multicast. Gossips regularly to a random subset of group members to retransmit missing messages. Gossiping is used both for bringing all members to the same state (having received the same messages) and to garbage-collect messages seen by all members (gc is piggybacked in gossip messages). See DESIGN for more details.
• GMS: Group membership protocol. Handles joins/leaves/crashes (suspicions) and emits new views accordingly. Use VIEW_ENFORCER on top of this layer to make sure new members don't receive any messages until they are members.
• CoordGmsImpl: Coordinator role of the Group MemberShip (GMS) protocol. Accepts JOIN and LEAVE requests and emits view changes accordingly.
• MergeData: Encapsulates data sent with a MERGE_RSP (handleMergeResponse()) and INSTALL_MERGE_VIEW (handleMergeView()).
• GmsImpl
• Gossip
• JoinRsp

Home | Contact Us | Privacy Policy | Terms of Service