[ https://issues.jboss.org/browse/JGRP-1548?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1548: --------------------------- Description: 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 only 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 form M500 is sent 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. If the was: 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 an ack, 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 only 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 form M500 is sent 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. If the -- 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

[ https://issues.jboss.org/browse/JGRP-1548?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1548: --------------------------- Description: 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. was: 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 form M500 is sent 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. If the -- 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

[ https://issues.jboss.org/browse/JGRP-1548?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-1548: ------------------------------------ +1 to send a time-based STABLE message with a fixed delay after the latest STABLE message, regardless of why it was sent. A STABLE message could also reset the bytes counter, so that a size-triggered STABLE message is not sent immediately. I think we talked about a similar idea to send STABLE messages with a fixed delay after the last sent message. That would handle the problem of a single message being sent and dropped, but if I remember correctly you were concerned of the very high overhead of re-scheduling the task to send the STABLE message all the time. -- 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