<div dir="ltr"><div class="gmail_default" style="color:#3333ff">Andy,</div><div class="gmail_default" style="color:#3333ff"><br></div><div class="gmail_default" style="color:#3333ff">I have one more quick question regarding mbedtls behavior.</div><div class="gmail_default" style="color:#3333ff">Given that one TLS frame may be fragmented at TCP layer, mbedtls might need to call multiple recv() before it can decrypt the packet.</div><div class="gmail_default" style="color:#3333ff">I do notice that lws_http_client_read eventually calls mbedtls_ssl_read which has a handshake loop, i.e., <span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-family:Menlo;font-size:14px">mbedtls_ssl_handshake</span>. Does this mean that LWS thread will be blocked until all related TCP segments has been received and decryption is done?</div>





</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 4, 2018 at 12:24 AM Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 04/10/18 15:06, Xi Chen wrote:<br>
> Thanks for your insights Andy.<br>
> <br>
> Unfortunately the platform is some RTOS running on tiny MCU, which is <br>
> not powerful at all.<br>
<br>
Even RTOS have a thread concept though.<br>
<br>
> The thread pool approach is not possible for me.<br>
<br>
If it's not pthreads or pthreads-compatible, then no.<br>
<br>
> For TLS, seems the solution is to speed it up by using other optimized <br>
> libraries?<br>
<br>
Not if mbedtls is the only thing on your platform.  1 x TLS will cost <br>
whatever it costs timewise, but if you have multiple connections coming, <br>
you should look at HTTP/2.  It can provide all your assets like pictures <br>
etc on the same TLS connection.  This works well on ESP32 it should work <br>
on your box.<br>
<br>
> For flash I/O, might need to sacrifice RAM by maintaining another copy <br>
> of received data, and write it later to flash by different task?<br>
<br>
You can do that, or read again more closely about using a second thread <br>
+ rx flow control.<br>
<br>
> Have you helped with other guys on similar topics before, i.e., porting <br>
> LWS on resource tight platforms? I do notice that there is esp32 <br>
> support, but not many related sample apps I can find in this area.<br>
<br>
Nobody pays me to look at it... if people like yourself who feel I <br>
should be spending my life doing that or other stuff want to actually <br>
fund it (or contribute it directly...), it can happen.<br>
<br>
-Andy<br>
<br>
> On Wed, Oct 3, 2018 at 11:40 PM Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <br>
> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>> wrote:<br>
> <br>
> <br>
> <br>
>     On 04/10/18 14:14, Xi Chen wrote:<br>
>      > Hi, Andy<br>
>      ><br>
>      > I need help with dealing the following scenarios:<br>
> <br>
>     What is the platform, something really weak?<br>
> <br>
>      > [Server case - CPU]<br>
>      > - With mbedtls, the crypto job might be CPU-intensive, which will<br>
>     block<br>
>      > the LWS thread. This affects the concurrency capability supported by<br>
>      > LWS, right? Is it by design of LWS?<br>
> <br>
>     Lws is nonblocking and singlethreaded, so yes it is by design.  You<br>
>     can't stop the event loop thread by spinning it in your code without<br>
>     stopping handling of events... this is a characteristic of all event<br>
>     loops not just lws.<br>
> <br>
>     So you have to adapt your design if you won't block the event loop.<br>
> <br>
>      > [Server case - I/O]<br>
>      > - Suppose server receives a POST request and need to save the<br>
>     data on<br>
>      > flash. I believe the flash write is blocking most likely, and is not<br>
>      > recommended to run in LWS callbacks. In this case, what is the<br>
>      > recommended way to deal with flash write in efficient way?<br>
> <br>
>     ... it depends on your platform resources and situation.<br>
> <br>
>     If your platform is not very constrained, there's no good reason to use<br>
>     mbedtls when OpenSSL has many optimized implementations for common<br>
>     platforms.  OpenSSL is literally 20+x faster for common tls operations<br>
>     on x86_64.  (And OpenSSL maintainers are not high on NIH.)<br>
> <br>
>     The write to serial flash situation you describe exists on the lws<br>
>     ESP32<br>
>     stuff, when you upload the OTA firmware.  But because it's a modal<br>
>     firmware upgrade type situation, it's OK to block other things.<br>
> <br>
>     To solve it, you have to move the slow activity to another thread or<br>
>     process.  That could take the form of buffering the data to be written<br>
>     in RAM and writing it separately (obviously the wisdom of that depends<br>
>     entirely on device resources...), or starting a thread when you see the<br>
>     requested task needs it and using rx flow control to modulate accepting<br>
>     new data against the progress of writing the last lot.  But I have not<br>
>     spent any time on http/2 rx flow control yet so this is only good<br>
>     for h1<br>
>     as it stands.<br>
> <br>
>     In the case the pattern is a client request triggers something that<br>
>     takes a long time to complete before generating output, if your<br>
>     platform<br>
>     is strong enough to support pthreads then look at threadpool:<br>
> <br>
>     <a href="https://libwebsockets.org/git/libwebsockets/tree/lib/misc/threadpool" rel="noreferrer" target="_blank">https://libwebsockets.org/git/libwebsockets/tree/lib/misc/threadpool</a><br>
> <br>
>     This lets a wsi defer answering on a connection until something it<br>
>     wanted to execute completed on a thread from a threadpool.  The event<br>
>     loop continues on as soon as the job is queued on the threadpool.  And<br>
>     the job can sync with the original wsi WRITEABLE callback when it is<br>
>     ready.  The advantage is lws absorbs ALL the thread synchronization<br>
>     stuff, you don't have to use any pthreads in your code.<br>
> <br>
>     There's a minimal example for it here:<br>
> <br>
>     <a href="https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-server/minimal-ws-server-threadpool" rel="noreferrer" target="_blank">https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-server/minimal-ws-server-threadpool</a><br>
> <br>
>     Gitohashi (the git web interface those links use) runs everything via<br>
>     threadpool, because stuff like the blame view can be slow to generate.<br>
>     By using threadpool a slow job doesn't cause any delay for other<br>
>     clients<br>
>     (until the pool of threads is wholly occupied).  And it can be<br>
>     running n<br>
>     slow jobs on n cores that way, giving a speedup overall.<br>
> <br>
>     -Andy<br>
> <br>
>      > Thanks<br>
>      > -Xi<br>
>      ><br>
>      ><br>
>      > _______________________________________________<br>
>      > Libwebsockets mailing list<br>
>      > <a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>     <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>><br>
>      > <a href="https://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">https://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>      ><br>
> <br>
</blockquote></div>