[jboss-jira] [JBoss JIRA] Commented: (JGRP-968) UNICAST: loss of first msg after asymmetric close causes all further messages to be lost

[Bela Ban (JIRA)]

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

Bela Ban commented on JGRP-968:
-------------------------------

SOLUTION: we need to send the conn-id with *every* message ! We also add a field 'first' to indicate the first message (may not be #1 all the time, e.g. for case #4, A sends a seqno > #1).
This fixes #6 because:
- B receives #2 but the conn-id is different from the recv-conn-id it has for A: since 'first' is not set, #2 is dropped
- B receives #1 (first=true): it trashes its receiver window and creates a new one with #1
- A retransmits #2, B adds #2 and so on

> UNICAST: loss of first msg after asymmetric close causes all further messages to be lost
> ----------------------------------------------------------------------------------------
>
>                 Key: JGRP-968
>                 URL: https://jira.jboss.org/jira/browse/JGRP-968
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.10.merge, 2.8
>
>
> This is scenario #6 in UNICAST.new.txt
> #4 A closes the connection unilaterally (B keeps it open), then reopens it and sends a message:
> - A removes the entry for B from its connection table, cancelling all pending retransmissions
> - (Assuming that B's entry.recv_win for A is at #25)
> - A creates a new entry for B in its connection table
> - Entry.send-conn-id is set and sent with the message
> - Entry.seqno now is 1
> - B receives the message with a new conn-id
> - B does have an entry for A, but entry.recv-conn-id doesn't match msg.conn-id
> - B creates a new entry.recv_win, sets it to msg.seqno
> - B sets entry.recv-conn-id to msg.conn-id
> #6 Same as #4, but after re-establishing the connection to B, A loses the first message
> (first part of #4)
> - A creates a new sender window for B
> - A sends #1(conn-id=322649) #2(conn-id=0) #3(conn-id=0), but loses #1
> - B receives #2 first. It thinks this is part of a regular connection, so it doesn't trash its receiver window
> - B expects a seqno higher than #2 (from the prev conversation with A), and discards #2, but *acks* it nevertheless
> - A removes #2 from its sender window
> - B now finally receives #1, and creates a new receiver window for A at #1
> - A retransmits #3
> - B stores #3 but doesn't deliver it because it hasn't received #2 yet
> - However, B will *never* receive #2 from A because that seqno has been removed from A's sender window !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira