Consistent http failures on every 5th request

Hardware GIGA R1
21

Hi @schnoberts , any update on your issue? You know your stuff so I'm sure we'd love some feedback.

1 Like
22

Hi,

I will definitely provide one when I get back to it. I got waylaid by a more critical problem related to USB driver issues (turned out to be a brown out) but that’s all sorted so I have an RTC clock to integrate and a TZ database to add then I’ll be back on the http case I suspect.

I do have a custom build of mbed as advised so I can debug it now :slight_smile:

23

I do have a question though, and maybe you can answer it because you seem familiar with the client code. The giga/mbed uses lwip which has configurable buffer sizes. Assume these are configured properly why is there a need for a background read thread in the Client code - assuming a well designed app that services the socket in a timely fashion? Is this a product of needing to support the lowest common denominator h/w wise?

24

I guess the idea is to move the data from the LwIP memory manager to a buffer specific for the connection. this allows applications with more connections use the same LwIP memory size as small application.

25

This is good to know. It suggests I can write a Client that doesn't do the extra read thread stuff and perhaps side step the issues with the current implementation because I know I don't have a lot of connections open.

26

We are here: Every 5th TCP connection fails on Arduino Giga R1 if we don't fully read the HTTP content sent from the server each time · Issue #937 · arduino/ArduinoCore-mbed · GitHub

In essence the issue appears to be this:

  1. You are downloading a body of data from a server.
  2. That server supports keep-alives.
  3. The body of data is larger than the TCP Window you advertise (which is derived from the max segment size parameter in the MBED config).
  4. You stop reading the socket (because you didn't like what was sent to you perhaps or you only needing the first N bytes of it) and close the connection.

It would appear in this situation that the server may continue to send keep-alives and this keeps the Giga's TCP stacks socket open in some half closed state and the resources are tied up until a timeout is reached.

My conclusion (currently) is this is a bug and the Giga's stack should be more aggressive in considering the connection dead since it sent a reset, but you can read the thread for yourself obv. I have a workaround, which is that I must always consume everything sent even when I don't need to.

Everyone on that ticket and this thread have been very helpful. @pennam 's PCAPs really nailed the cause down. (The n/w my Giga is on doesn't allow passive captures).

1 Like