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 !