Time-Sensitive TCP server

[felixdoerre]

Hi,

I've got an explanation for this bug: https://github.com/usedbytes/serial-flash/blob/51e30aae59cde7daa17cb43accabf6d1315964b8/main.go#L80

What happens:

• Client connects
• tcp_comm_client_init is called
  • the gpio led turns on https://github.com/usedbytes/picowota/blob/main/tcp_comm.c#L461
  • While communicating with the cyw43 to enable the led, network packages are discovered that need to be processed, incl. the initial opcode.
  • the recv-callback is not set yet, so the callback invocation is skipped
• tcp_comm_client_init continues to set up callbacks, the initial data is lost.

A fix seems to be, that the gpio pin is not turned on directly inside an lwip callback, but dispatched to the main loop as an event.

In general the TCP implementation seems to be very sensitive to timing/packeting. Sending multiple commands at once or sending commands before having received the previous reply confuses the handling code, resulting in skipped data, or plain hangups. This is generally not expected from TCP peers. Is it desired to make the tcp client more robust against this?