]
Bela Ban resolved JGRP-1874.
----------------------------
    Resolution: Duplicate Issue
 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.1, 3.6
 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 previous 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