When implementing #152, we recognized that peers can get stuck when the last Payload or PayloadAck gets lost.
The reason is, that one side assumes too early it is ready and stops
This causes the PayloadSender never to receive a PayloadAck
With that the PayloadSender is never ready to stop. Thus, the Peer can't stop gracefully
Another, scenario that can happen is that on loaded systems the Peers make progress at different speeds, which can lead to that one Peer is much earlier ready than another one.
This can lead basically to a similar scenario where one of the Peers can't gracefully stop
We can fix this with a 4 way handshake, where the last ACK can get lost. However, the Peer which is waiting for the ACK than needs to wait a certain time
This is similar to the tcp close except that in our case both Peers send the FIN message independent of each other and the peer which did yet receive a FIN from the other node needs to stay alive and potentially receive messages and react on them
Background
Acceptance Criteria
Out of scope