[
https://jira.jboss.org/jira/browse/JGRP-968?page=com.atlassian.jira.plugi...
]
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