- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Solved! Go to Solution.
- Labels:
-
WICED Studio
-
Wireless MCU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
<<<<<<<<<<<<<>>>>>>>>>>>>>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
<<<<<<<<<<<<<>>>>>>>>>>>>>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.