1

I use an embedded IP stack on my device (it is a uIP clone). It runs on a microcontroller with limited resources. This stack currently only works as HTTP server (the device has built in small web server with minified pages and small files).

When my server handles HTTP requests from clients (browsers), it sends the data to the client normally but waits for an acknowledge each time a single TCP packet is sent out. But the acknowledge from client (browser) usually comes after 50ms. I was looking for what this could cause and why acknowledge wouldn't come sooner. After all, 50ms is a very long time. And I found that this is caused by TCP delayed acknowledgments, https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment.

The question now is how to disable this in operating systems on which these browsers are running. Eg. as part of establishing communication (SYN and SYNACK packets). To instruct them not to wait with the acknowledges, but to send them immediately.

I know from other answers that these ACKs can be individually disabled for each OS, (eg. in Linux Disable TCP Delayed ACKs), but I need to disable it on my side, ie on the server side. And reliably for every connected client. Just for the communication with my device.

I also know that support for these delayed ACKs could be added to my embedded IP stack but I don't want to do this (eg. to send more data without waiting for an ACK). I also know that another embedded stack could be used, which might already have that support (newer lwIP seems to have that one), but that I don't want either.

I'm not aware of such feature in the TCP protocol (to be able to turn the delayed ACKs off from server side) but maybe I'm missing something?

tk_
  • 490
  • 3
  • 15
  • @DavidSchwartz The uIP stack sets PSH flag on every packet that carries data, by its design. The flag does different thing, is not a solution. The only solution I see now is to send more data, up to the size of advertised window or 2xMSS, whichever is smaller (Nagle is not supported there either so there should not be a problem). It means to enhance the uIP stack or use different embedded IP stack. I used the uIP because of its small memory footprint, the downside is that it lacks some important features... – tk_ Dec 31 '21 at 10:35
  • I don't see any tcp options to tell the other side not to delay ACKs. You can check tcp roadmap (rfc7414) or [this iana registry](https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml), maybe you will find something. However, TCP was always supposed to have a window, so I would not assume there are any optimizations for the window of one. – Effie Dec 31 '21 at 14:49
  • I saw somewhere a suggestion to send two packets with 1/2 MSS each. But then you will have to manage the window. And I am not sure if there is no protection against this stuff. – Effie Dec 31 '21 at 14:52

0 Answers0