org.jgroups.protocols

Class NAKACK

public class NAKACK extends Protocol

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 messages destined for an upcoming view, or discard messages sent in a previous view. Both modes reset their seqnos to 0 when receiving a view change. The NAK_ACK scheme is used for broadcasting view changes.

The third mode is for out-of-band control messages (activated by SWITCH_OUT_OF_BAND): this mode does neither employ view IDs, nor does it use the same seqnos as NAK and NAK_ACK. It uses its own seqnos, unrelated to the ones used by NAK and NAK_ACK, and never resets them. In combination with the sender's address, this makes every out-of-band message unique. Out-of-band messages are used for example for broadcasting FLUSH messages.

Once a mode is set, it remains in effect until exactly 1 message has been sent, afterwards the default mode NAK is used again.

The following communication between 2 peers exists (left side is initiator, right side receiver):

 

send_out_of_band --------------> synchronous (1) <------------- ack

send_nak --------------> asynchronous (2)

send_nak_ack --------------> synchronous (3) <-------------- ack

retransmit <-------------- asynchronous (4)

When a message is sent, it will contain a header describing the type of the message, and containing additional data, such as sequence number etc. When a message is received, it is fed into either the OutOfBander or NAKer, depending on the header's type.

Note that in the synchronous modes, ACKs are sent for each request. If a reliable unicast protocol layer exists somewhere underneath this layer, then even the ACKs are transmitted reliably, thus increasing the number of messages exchanged. However, since it is envisaged that ACK/OUT_OF_BAND are not used frequently, this problem is currently not addressed.

Author: Bela Ban

Method Summary
voiddown(Event evt)
Callback.
StringgetName()
voidinit()
Do some initial tasks
VectorprovidedDownServices()
VectorprovidedUpServices()
booleansetProperties(Properties props)
todo Maybe messages from previous vids are stored while client
voidstop()
voidup(Event evt)
Callback.

Method Detail

down

public void down(Event evt)
Callback. Called by superclass when event may be handled.

Do not use passDown in this method as the event is passed down by default by the superclass after this method returns !

getName

public String getName()

init

public void init()
Do some initial tasks

providedDownServices

public Vector providedDownServices()

providedUpServices

public Vector providedUpServices()

setProperties

public boolean setProperties(Properties props)
todo Maybe messages from previous vids are stored while client

stop

public void stop()

up

public void up(Event evt)
Callback. Called by superclass when event may be handled.

Do not use passUp() in this method as the event is passed up by default by the superclass after this method returns !

Copyright ? 1998-2005 Bela Ban. All Rights Reserved.