[jboss-jira] [JBoss JIRA] (JGRP-1548) UNICAST2: send STABLE message after 'last received' message

Gray Watson (JIRA) jira-events at lists.jboss.org
Tue Jan 29 09:33:48 EST 2013


    [ https://issues.jboss.org/browse/JGRP-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751065#comment-12751065 ] 

Gray Watson commented on JGRP-1548:
-----------------------------------

Maybe we should not bundle OOB messages or something?  Or maybe a flag could be set on a message that disables bundling for it?
                
> 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: http://www.atlassian.com/software/jira


More information about the jboss-jira mailing list