ESP8266 Community Forum

TCP looks fast enough for me, I need to send data at 20ms intervals, the send usually takes about 2ms, plus I can buffer some data, so there looks to be enough headroom. The problem happens only when it needs to resend after failed send, ESP waits for about 1 seconds before resend, which is an extremely long time. I believe there should be some way of changing this, does someone know how?

rudy wrote:I have not looked at faster TCP options.

With games, TCP is too slow for quickly changing events. And what is often done is using UDP with multiple sends. A message ID count is used to determine if it has already been received. If it has it throws away the duplicate messages. Typically three messages are sent (with slight delays) and that should take care of any recoverable situations.

ponasP wrote:TCP looks fast enough for me, I need to send data at 20ms intervals, the send usually takes about 2ms,

As long as you never need to do retries, then I guess TCP is fast enough for you. But TCP is not designed to be fast, and reliable, when there are errors.

TCP is designed to be a reliable 'stream' protocol and that is why the individual packets can suffer delays if a transmission gets lost. In a stream application with buffers the delays get covered up and become less important. The typical delays used for re-transmission have to take into account that a packet journey across the internet can take a while for a normal ack to return. It is not really intended for fast short packet applications which is why it tends not to get used in things like gaming.

You can tweak the re-transmission time in the source code of the tcp stack but I wouldn't recommend doing that.

As Rudy suggested UDP is the better base protocol for short fast packet transmission. It is a fire and forget protocol which means there is no guarantee of delivery or automatic recovery, but that does mean that it is all under your control. You can either send multiple times if you want to play statistics or you can do your own fast ack through a back UDP channel with a resend if no ack received. That means the timing is under your control and can take into account expected transit times.

I have decided to go with UDP and implement my own checks/retransmits only where needed as per your suggestion. So far so good. Thanks for your help!

btidey wrote:TCP is designed to be a reliable 'stream' protocol and that is why the individual packets can suffer delays if a transmission gets lost. In a stream application with buffers the delays get covered up and become less important. The typical delays used for re-transmission have to take into account that a packet journey across the internet can take a while for a normal ack to return. It is not really intended for fast short packet applications which is why it tends not to get used in things like gaming.

You can tweak the re-transmission time in the source code of the tcp stack but I wouldn't recommend doing that.

As Rudy suggested UDP is the better base protocol for short fast packet transmission. It is a fire and forget protocol which means there is no guarantee of delivery or automatic recovery, but that does mean that it is all under your control. You can either send multiple times if you want to play statistics or you can do your own fast ack through a back UDP channel with a resend if no ack received. That means the timing is under your control and can take into account expected transit times.