SuperTCP retry queue & prevent double messages

Remoting SDK
#1

We have a Delphi implementation with the RemObject superTCP channel with Binary messages.
It looks like, sometimes our server gets messages twice and also handles them twice. After looking into the code, I saw the AckWaitYimeout on the client was set to 2000 (ms). I know the customer has a poor network connection from the location this action was initiated.

Two questions:

  1. Can this low time cause messages are sending twice to our server?

  2. Is there some best practice to prevent this kind of errors? Of course increasing the timeout client side is an option, but maybe there’s also an server side option? I think of checking (per session) the incomming message id’s (and cache time for a time X) to see if we have dupplicates

#2

Hi,

each request/response should be confirmed that it was received, by default.
you can change this behavior with the SkipAck property, but in this case, other side can lose some messages due network failure.

another workaround - change SuperTcp channel with other plain channel, like plain tcp

#3

So what I’m thinking is happening, receiving the message twice, shouldn’t be possible by default?

#4

it can happen when sender-side doesn’t receive confirmation from other-side, so it resends message.

#5

In this case, the message from client is send twice to server. Is there an option to check message id’s per session (and cache these for lets say a few minutes), so before a message is processed, we can check if it wasn’t processed earlier?

#6

Hi,

No, you can’t this possibility.
can you check that AckWaitTimeout is set equal on both sides (in channel and server components)?
if they are differ, it may lead to errors…

#7

Both are set to default, still having issues (last one was this morning), that messages are received multiple times.
In this case, a message was handled (end probably send) 6 times, customer told me the client application was freezing (I assume due to network troubles), they killed the client application.
The freeze of the application is probably because it isn’t async, and it was just waiting the full 10seconds for a response, didn’t had it, retried, etc…

#8

you could catch a situation, when TCP itself performs retransmissions of lost packages.

from https://en.wikipedia.org/wiki/Packet_loss:

Packet loss occurs when one or more packets of data travelling across a computer network fail to reach their destination. Packet loss is either caused by errors in data transmission, typically across wireless networks, or network congestion. Packet loss is measured as a percentage of packets lost with respect to packets sent.

The Transmission Control Protocol (TCP) detects packet loss and performs retransmissions to ensure reliable messaging. Packet loss in a TCP connection is also used to avoid congestion and thus produces an intentionally reduced throughput for the connection.

if your client has a bad wireless connection, TCP may retransmit unconfirmed packages. as a result, server may receive duplicated packages