In the NetworkPacketResender it can mean a problem if we resend the message twice and we receive a response twice

[benedekh]

in a sense that for the first send the recipient did not react. However, after a while the recipient 'wakes up' and progresses the first request and sends a response for that. At the same time, we resend the request because we haven't received a response on time (for the first request). But after that we receive the response for the first request and later for the second request too.

We accept the first response, but when we send a third request that is completely different from the first (and the second which was a resend) we receive the response for the second request (because it is already arrived on our side, but we havent't progressed it).

To clarify the issue with a simple example:

KVClient sends a PUT hello world request to server. The KVServer does not respond in time for this request, so the client resends that. However, after a while the KVServer wakes up and progresses the first request, sends a response for that (i.e. PUT_SUCCESS). Right after that it progresses the resent first request too and sends a response for that (i.e. PUT_SUCCESS).

After the KVClient received the first response (PUT_SUCCESS), it returns to some other part of the code (e.g. KVClient CLI prompt).

Next, the KVClient sends a GET hello request. Now, it receives the second response (because it had arrived to the client but was not progressed yet, because of waiting for the CLI prompt) and it interprets as an invalid response because it expects a GET_SUCCESS world instead of that.

This issue can arise, if the consecutive requests use the same ICommunicationApi instance, and there is no automatic response packet dispatching mechanism (e.g. a separate thread that always accepts and dispatches received responses independent from the send and independent from the fact that we expect for a response).

[benedekh]

@banctilrobitaille Are we going to deal with this issue?