snip.https_server application dies with repetitive client requests (CYW943907AEVAL1F)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ChMa_3922746
Level 5
Level 5
10 likes received 10 likes given 5 likes given

The HTTPS server that is called by the snip.https_server application dies with repetitive client requests. 

If you simply build the default application (SDK 6.4), then run it, you will see that the server permanently fails if you send closely-spaced client requests.  You can do this by simply making a bookmark to the device URL (e.g., https://192.168.2.157/apps/https_server/https_server_top.html), then clicking on the link in quick succession (e.g., 2 to 5 times/sec).  After a few seconds of clicking, the server dies (Firefox indicates no further pages are served).

Note that the function http_server_deferred_connect_callback() still appears to be called, but nothing happens after it is called.

Any help is appreciated.

Thanks!

0 Likes
1 Solution

Hi,

High concurrency could exhaust the resource of the MCU and hence result in the failure you saw.

Since the code example didn't use multi-threading, the result is expected to be worse facing high concurrency.

The code is provided for demonstration and is not intended to cover high concurrency situation. You can try to improve it by yourself, making the improvements at your need.

<<<<<<<<<<<<<>>>>>>>>>>>>>

Sincere regards from​ C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>

View solution in original post

0 Likes
4 Replies
ChMa_3922746
Level 5
Level 5
10 likes received 10 likes given 5 likes given

By the way, it is much easier to reproduce if you make a page that takes a little longer to render.  For example, if you modify the file resources/https/server/https_server_top.html by adding a couple of thousand lines of print (to emulate a page that is rendered dynamically by the CPU), then it is easy to reproduce.

0 Likes

Hi,

High concurrency could exhaust the resource of the MCU and hence result in the failure you saw.

Since the code example didn't use multi-threading, the result is expected to be worse facing high concurrency.

The code is provided for demonstration and is not intended to cover high concurrency situation. You can try to improve it by yourself, making the improvements at your need.

<<<<<<<<<<<<<>>>>>>>>>>>>>

Sincere regards from​ C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>

0 Likes

Thank you.  By inserting delays in ssl_tls.c, I observe that it is more robust against this condition.  I will keep testing and report back.

0 Likes

Update:  I have been pounding the webserver for a few days and it seems to be stable.  No hanging.  I suspect you were correct in saying the system resources were being exhausted.  Perhaps the malloc's built-up quickly until there was no memory left.  By adding delays as indicated, the peak malloc's likely no longer reach the point of exhaustion.  So, case closed.  Thanks for your help on this.

0 Likes