[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