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

Wi-Fi Combo

ChMa_3922746
Level 5
10 likes received 10 likes given 5 likes given
Level 5

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
Charles_Lai
Moderator
Moderator 250 replies posted 100 solutions authored 100 replies posted
Moderator

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
10 likes received 10 likes given 5 likes given
Level 5

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
Charles_Lai
Moderator
Moderator 250 replies posted 100 solutions authored 100 replies posted
Moderator

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
ChMa_3922746
Level 5
10 likes received 10 likes given 5 likes given
Level 5

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
ChMa_3922746
Level 5
10 likes received 10 likes given 5 likes given
Level 5

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