[jboss-jira] [JBoss JIRA] (JGRP-1594) UNICAST3: introduce connection establishment / teardown

[Bela Ban (JIRA)]

Bela Ban created JGRP-1594:
------------------------------

             Summary: UNICAST3: introduce connection establishment / teardown
                 Key: JGRP-1594
                 URL: https://issues.jboss.org/browse/JGRP-1594
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.3


[Use case: UNICAST_ConnectionTests.testBClosingUnilaterally()]

There can be issues when simply sending messages with a conn-id, and the peer closing the connection, e.g.:

* A and B have connections (send,receive) to each other
* A sends 10 messages to B on conn-id=1
* B accepts the 10 messages and passes them up
* B closes its connection (but hasn't sent ack(10) yet)
** Closing the connection, B removes the receive table for A
* A hasn't received an ACK so it resends the 10 messages with conn-id=1
* B creates a new connection for A and a new (empty) receive table
** B now accepts the 10 *retransmitted* messages from A and delivers them

B therefore delivers the 10 messages *twice* !

SOLUTION #1:
* When closing a connection, don't *remove* it immediately, but only mark is as closed and keep it around for a few minutes
* A reaper then removes connections that have been marked as closed and have been idle for a few minutes
** If messages are received for a closed connection on the same conn-id, remove the closed mark and treat the connection as open again
*** If A resent the 10 messages, B would still have the receive window, and know that it already received the 10 messages from A and discard them, preventing duplicate delivery

SOLUTION #2:
* Introduce explicit connection establishment and teardown, similar to TCP
* When creating a connection to B, run a simplified SYN-ACK protocol, whereby both parties establish their sending and receiving conn-ids (perhaps also seqnos)
* When closing a connection, run a simplified FIN-ACK protocol
** This would prevent A from resendin the 10 messages, as the send table would have been removed
* Connection creation and teardown should be time bounded, ie. if a connection cann be created to a peer after some attempts and timeout, throw an exception, which propagates back to the caller, If a connection cannot be closed (e.g. no ACK is received for the FIN), simply close it unilaterally

--
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