]
Bela Ban commented on JGRP-1548:
--------------------------------
The good thing about sending STABLE messages that was not mentioned above is that a sender
does not need to store messages for a long time; as soon as a STABLE(22) message is
received, the sender can purge all messages <= 22.
On the downside, we'll be sending way more STABLE messages than with the current
scheme, so they need to be small and efficient, like ACKs in UNICAST.
UNICAST2: send STABLE message after 'last received' message
-----------------------------------------------------------
Key: JGRP-1548
URL:
https://issues.jboss.org/browse/JGRP-1548
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
Contrary to UNICAST, which acks every message, UNICAST2 never acks messages, but only
asks the sender to retransmit a message when a gap has been detected.
However, the drawback of this (negative ack) mechanism is the so called
last-message-dropped problem: when A sends messages [1..5] to B, but 5 is dropped by the
transport, as A doesn't retransmit messages until it gets a retransmission request
from B, B only gets messages [1..4].
B will *not* ask A to retransmit message 5, as B doesn't know A *sent* message 5 in
the first place.
If A doesn't send message 6 for B to detect 5 is missing and asking A for
retransmission, B won't get that message.
The way this is currently handled is with stable messages. A STABLE message is sent from
B to A every stable_interval ms or whenever M bytes from A have been received. In the
worst case, B will have to wait stable_interval ms until it finally receives message 5
from A.
SOLUTION:
In addition to time and size based STABLE messages, we could send a STABLE message
whenever the batch of messages removed from the receive window has completed and the
receive window is empty.
This would send a STABLE message immediately when a single message has been received (and
no other messages from A are in the receive window), but it would send another STABLE
message only when all (e.g.) 200 messages from A have been processed and the receive
window is empty.
With this new mechanism, we could even remove the time-based STABLE messages !
Example:
- At time T0, messages M1 and M2 are received. A STABLE message for M2 is sent.
- At T+500 (ms), messages M3-M100 are received. A STABLE message for M100 is sent
- At T+1500, M101 is received. A STABLE message for M101 is sent.
- At T+2000, M102 is received. A STABLE message for M102 is sent.
- At T+2010, M103-M500 are received. A STABLE message for M500 is sent
(Note that the example above didn't take size-based STABLE messages into account)
This is similar to the ACK based scheme in UNICAST where we only send an ack for the last
message in a batch (or for a single message if not batch has been received).
This new mechanism needs to be configurable: if enabled, the time-based STABLE mechanism
would be disabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: