2 of 2 people found this helpful
This is likely because your web browser is opening 5 or 6 TCP connections to your WICED device simultaneously. Depending on which HTTP server implementation you're using, most of these should probably be closed immediately (due to their being insufficient RAM to perform TLS over each simultaneously) but might instead be left hanging. (I.e. the HTTP resources requested via those connections may be left waiting on a long TCP timeout and may fail to be retrieved altogether.)
Another factor is HTTP keep alives. If the HTTP server implementation you're using does not allow this, then a new TCP socket and TLS session must be established for each HTTP resource being requested. The latter is fairly resource intensive and would be quite slow to run multiple times in succession. It may be necessary to customize the HTTP server implementations provided to enable support for keep alives.
Thanks for the response. The server we are using is based off of the HTTP_Server in the daemon folder in WICED (with some custom stuff added).
After a little more debugging, I am seeing that the server just isn't receiving the resource requests from the browser. I have gone down as far as I can with NetX and I've yet to figure out exactly why that is.
Looking at that module, it looks like it uses TCP socket server pool which will try to support multiple simultaneous connections. If you look at the implementation of 'http_server_deferred_connect_callback()' however, you'll see where incoming TCP connections are left hanging if your device is out of memory.
Cypress should fix this scenario to formally reject the incoming TCP socket connection if there's not enough memory for the needed TLS context.