When A gets unicast messages from B, then A creates a ReceiverEntry in its recv_table for B. The creation (or fetching of the existing ReceiverEntry) is done under a lock, however, the adding and subsequent removal of messages is not done under a lock (well, actually, adding messages to ReceiverEntry.win is locked).

What could happen is the following:

• B sends messages 1,2,3 (conn-id=5)
• B closes the connection to A
• B sends messages 1,2,3 to A (new conn-id=6)
• A receives messages 1,2,3 with conn-id=5
• A grabs the ReceiverEntry for B and starts adding 1,2,3 to win
• Messages 1-3 from B with conn-id=6 are received
• This creates a new ReceiverEntry for B
• A now starts removing and passing up messages 1-3 from B with the old conn-id 5
• A receives messages 1-3 from B with conn-id=5
• Subsequently, A also receives messages 1-3 from B with conn-id=6

Not sure if this really constitutes a bug, but I nevertheless need to take a look.
Possible solution:

• Create receiverEntry for B only once
• Remove ReceiverEntry for B only when the view excludes B, but not when B sends messages with a different conn-id
• Instead, lock on the ReceiverEntry for B when messages are received:
  • When a message with a different conn-id is received, only change the contents of ReceiverEntry (e.g. conn-id, reset win etc), but don't remove the ReceiverEntry from recv_table and create a new one