[jboss-jira] [JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1874:
---------------------------
    Description: 
When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
Example:
# B has no entry for A in its recv-table
# A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
# If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
#* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO message}}: too much traffic
# A now sends messages {{A::101}} - {{A::560}} to B
#* This is also not needed: too much traffic

h5. Solution to reduce traffic
* Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
* Sender: when a {{GET-FIRST-SEQNO(560)}}  message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
** B will then retransmit all missing messages in that range
** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission

  was:
When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
Example:
# B has no entry for A in its recv-table
# A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
# If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
#* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRS-SEQNO message}}: too much traffic
# A now sends messages {{A::101}} - {{A::560}} to B
#* This is also not needed: too much traffic

h5. Solution to reduce traffic
* Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
* Sender: when a {{GET-FIRST-SEQNO(560)}}  message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
** B will then retransmit all missing messages in that range
** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission



> UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
> -----------------------------------------------------------
>
>                 Key: JGRP-1874
>                 URL: https://issues.jboss.org/browse/JGRP-1874
>             Project: JGroups
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
> Example:
> # B has no entry for A in its recv-table
> # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
> # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
> #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO message}}: too much traffic
> # A now sends messages {{A::101}} - {{A::560}} to B
> #* This is also not needed: too much traffic
> h5. Solution to reduce traffic
> * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
> ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
> * Sender: when a {{GET-FIRST-SEQNO(560)}}  message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
> ** B will then retransmit all missing messages in that range
> ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)