|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Objectorg.jgroups.stack.Protocol
org.jgroups.protocols.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 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.
Field Summary |
Fields inherited from class org.jgroups.stack.Protocol |
down_handler, down_prot, down_queue, down_thread, down_thread_prio, log, observer, props, stack, up_handler, up_prot, up_queue, up_thread, up_thread_prio |
Constructor Summary | |
NAKACK()
|
Method Summary | |
void |
down(Event evt)
Callback. |
java.lang.String |
getName()
|
void |
init()
Do some initial tasks |
java.util.Vector |
providedDownServices()
List of events that are provided to layers below (they will be handled when sent down from below). |
java.util.Vector |
providedUpServices()
List of events that are provided to layers above (they will be handled when sent down from above). |
boolean |
setProperties(java.util.Properties props)
Configures the protocol initially. |
void |
stop()
This method is called on a Channel.disconnect() . |
void |
up(Event evt)
Callback. |
Methods inherited from class org.jgroups.stack.Protocol |
destroy, getDownProtocol, getDownQueue, getProperties, getUpProtocol, getUpQueue, handleSpecialDownEvent, passDown, passUp, receiveDownEvent, receiveUpEvent, requiredDownServices, requiredUpServices, setDownProtocol, setObserver, setPropertiesInternal, setProtocolStack, setUpProtocol, start, startDownHandler, startUpHandler, stopInternal |
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Constructor Detail |
public NAKACK()
Method Detail |
public void init() throws java.lang.Exception
init
in class Protocol
java.lang.Exception
- Thrown if protocol cannot be initialized successfully. This will cause the
ProtocolStack to fail, so the channel constructor will throw an exceptionpublic void stop()
Protocol
Channel.disconnect()
. Stops work (e.g. by closing multicast socket).
Will be called from top to bottom. This means that at the time of the method invocation the
neighbor protocol below is still working. This method will replace the
STOP, STOP_OK, CLEANUP and CLEANUP_OK events. The ProtocolStack guarantees that
when this method is called all messages in the down queue will have been flushed
stop
in class Protocol
public java.lang.String getName()
getName
in class Protocol
public java.util.Vector providedUpServices()
Protocol
providedUpServices
in class Protocol
public java.util.Vector providedDownServices()
Protocol
providedDownServices
in class Protocol
public void up(Event evt)
Do not use passUp()
in this method as the event is passed up
by default by the superclass after this method returns !
up
in class Protocol
public void down(Event evt)
Do not use passDown
in this method as the event is passed down
by default by the superclass after this method returns !
down
in class Protocol
public boolean setProperties(java.util.Properties props)
Protocol
"loopback=false;unicast_inport=4444"
setProperties
in class Protocol
|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |