## $Id: CONFIGURATIONS,v 1.1.1.1 2003/09/09 01:24:04 belaban Exp $
Frequently used protocol stack specifications
=============================================
Virtual Synchrony & State Transfer Protocol Stack
-------------------------------------------------
UDP:
PING(num_initial_members=2;timeout=3000):
FD:
STABLE:
NAKACK:
UNICAST:
FRAG:
FLUSH:
GMS:
VIEW_ENFORCER:
STATE_TRANSFER:
QUEUE
Properties:
Uses Virtual Synchrony. All messages sent in a view V1 are delivered in
that view. The FLUSH protocol makes sure that, when a new view V2 is to
be installed, that all messages sent in V1 will be seen by all members
of V1 before V2 is installed. The FLUSH protocol stops all sending
until V2 has been installed successfully at all members. Messages sent
after the block has been received and before V2 is installed will be
sent in V2.
Protocols:
UDP: uses UDP/IP multicast as transport
PING: discovers initial set of members, determines coordinator to
which the join-request will be sent
FD: failure detection based on periodic pinging of member 'to the
right' in the membership ring
STABLE: garbage collection of messages seen by all members
NAKACK: guarantees lossless 1-m message delivery, uses negative acks
to retransmit lost messages
UNICAST: guarantees lossless 1-1 message delivery, uses positive acks
to retransmit lost messages
FRAG: fragments large messages into smaller ones and reassembles them
at the receiving side
FLUSH: flushes all pending multicasts out of the system before
transitioning to a new view. Ensures that all members of view
V1 agree on the set of messages they delivered in V1.
GMS: group membership service. Takes care of joining/leaving members
VIEW_ENFORCER: only accepts messages from senders in the same
view. Stores messages for future view, discards messages
sent in previous view.
STATE_TRANSFER: allows any member to fetch the state from any other
member (usually done immediately after joining)
QUEUE: queues messages sent during a view transition. When the new
view is installed, the stored messages will be sent.
Pbcast-based Protocol Stack
---------------------------
UDP(mcast_addr=228.1.2.3;mcast_port=45566;ip_ttl=0):
PING(timeout=5000;num_initial_members=6):
FD_SOCK:
VERIFY_SUSPECT(timeout=1500):
pbcast.STABLE(desired_avg_gossip=10000):
pbcast.NAKACK(gc_lag=5;retransmit_timeout=3000;trace=true):
UNICAST(timeout=5000;min_wait_time=2000):
FRAG(down_thread=false;up_thread=false):
pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=true)
Properties:
Defines a stack with weaker reliability semantics than the Virtual Synchrony protocol
stack. The biggest difference is that there is no guarantee that the set of messages
sent between views is the same (no FLUSH protocol). Essentially defines a reliable 1-m
protocol, where views are just regular messages and have no special semantics.
Protocols:
UDP: uses UDP/IP multicast as transport. Uses a time-to-live of 0
PING: discovers initial set of members, determines coordinator to
which the join-request will be sent. Will wait for 5 seconds or 6 members to
respond (whichever is first)
FD_SOCK: failure detection based on TCP socket connection from each member to the
member 'to the right' in the membership ring. When connection breaks, member
is suspected. Compared to FD, there are no periodic ping messages sent
VERIFY_SUSPECT: reduces false suspicions. Verifies that a member P that is suspected
is really dead by sending a ping message to P.
pbcast.STABLE: garbage collection of messages seen by all members using gossips. A
gossip is multicast every 10 seconds on average by each member.
pbcast.NAKACK: guarantees lossless 1-m message delivery, uses negative acks
to retransmit lost messages
UNICAST: guarantees lossless 1-1 message delivery, uses positive acks
to retransmit lost messages
FRAG: fragments large messages into smaller ones and reassembles them
at the receiving side
pbcast.GMS: group membership service. Takes care of joining/leaving members
