Deployed 2802cad with MkDocs version: 1.1

This commit is contained in:
2020-04-24 22:51:16 +00:00
parent 8f8d9e79bc
commit 99c1e62c9e
7 changed files with 20 additions and 14 deletions

View File

@ -95,6 +95,10 @@
<li class="nav-item" data-level="1"><a href="#changelog" class="nav-link">Changelog</a>
<ul class="nav flex-column">
<li class="nav-item" data-level="2"><a href="#940-2020-04-24" class="nav-link">[9.4.0] - 2020-04-24</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#933-2020-04-17" class="nav-link">[9.3.3] - 2020-04-17</a>
<ul class="nav flex-column">
</ul>
@ -688,6 +692,8 @@
<h1 id="changelog">Changelog</h1>
<p>All changes to this project will be documented in this file.</p>
<h2 id="940-2020-04-24">[9.4.0] - 2020-04-24</h2>
<p>(ssl) Add support for supplying SSL CA from memory, for OpenSSL and MbedTLS backends</p>
<h2 id="933-2020-04-17">[9.3.3] - 2020-04-17</h2>
<p>(ixbots) display sent/receive message, per seconds as accumulated</p>
<h2 id="932-2020-04-17">[9.3.2] - 2020-04-17</h2>

View File

@ -137,8 +137,7 @@
</ul>
<h2 id="limitations">Limitations</h2>
<ul>
<li>On Windows and Android certificate validation needs to be setup so that SocketTLSOptions.caFile point to a pem file, such as the one distributed by Firefox. Unless that setup is done connecting to a wss endpoint will display an error. On Windows with mbedtls the message will contain <code>error in handshake : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed</code>.</li>
<li>There is no convenient way to embed a ca cert.</li>
<li>On some configuration (mostly Android) certificate validation needs to be setup so that SocketTLSOptions.caFile point to a pem file, such as the one distributed by Firefox. Unless that setup is done connecting to a wss endpoint will display an error. With mbedtls the message will contain <code>error in handshake : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed</code>.</li>
<li>Automatic reconnection works at the TCP socket level, and will detect remote end disconnects. However, if the device/computer network become unreachable (by turning off wifi), it is quite hard to reliably and timely detect it at the socket level using <code>recv</code> and <code>send</code> error codes. <a href="https://stackoverflow.com/questions/14782143/linux-socket-how-to-detect-disconnected-network-in-a-client-program">Here</a> is a good discussion on the subject. This behavior is consistent with other runtimes such as node.js. One way to detect a disconnected device with low level C code is to do a name resolution with DNS but this can be expensive. Mobile devices have good and reliable API to do that.</li>
<li>The server code is using select to detect incoming data, and creates one OS thread per connection. This is not as scalable as strategies using epoll or kqueue.</li>
</ul>

View File

@ -263,5 +263,5 @@ webSocket.send(&quot;hello world&quot;);
<!--
MkDocs version : 1.1
Build Date UTC : 2020-04-22 21:14:51
Build Date UTC : 2020-04-24 22:51:16
-->

File diff suppressed because one or more lines are too long

View File

@ -1,35 +1,35 @@
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url>
<loc>None</loc>
<lastmod>2020-04-22</lastmod>
<lastmod>2020-04-24</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-04-22</lastmod>
<lastmod>2020-04-24</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-04-22</lastmod>
<lastmod>2020-04-24</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-04-22</lastmod>
<lastmod>2020-04-24</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-04-22</lastmod>
<lastmod>2020-04-24</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-04-22</lastmod>
<lastmod>2020-04-24</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-04-22</lastmod>
<lastmod>2020-04-24</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>None</loc>
<lastmod>2020-04-22</lastmod>
<lastmod>2020-04-24</lastmod>
<changefreq>daily</changefreq>
</url>
</urlset>

Binary file not shown.

View File

@ -518,7 +518,7 @@ server.wait();
<pre><code class="cpp">webSocket.setTLSOptions({
.certFile = &quot;path/to/cert/file.pem&quot;,
.keyFile = &quot;path/to/key/file.pem&quot;,
.caFile = &quot;path/to/trust/bundle/file.pem&quot;,
.caFile = &quot;path/to/trust/bundle/file.pem&quot;, // as a file, or in memory buffer in PEM format
.tls = true // required in server mode
});
</code></pre>
@ -528,7 +528,8 @@ server.wait();
<p>On a server, this is necessary for TLS support.</p>
<p>Specifying <code>caFile</code> configures the trusted roots bundle file (in PEM format) that will be used to verify peer certificates.
- The special value of <code>SYSTEM</code> (the default) indicates that the system-configured trust bundle should be used; this is generally what you want when connecting to any publicly exposed API/server.
- The special value of <code>NONE</code> can be used to disable peer verification; this is only recommended to rule out certificate verification when testing connectivity.</p>
- The special value of <code>NONE</code> can be used to disable peer verification; this is only recommended to rule out certificate verification when testing connectivity.
- If the value contain the special value <code>-----BEGIN CERTIFICATE-----</code>, the value will be read from memory, and not from a file. This is convenient on platforms like Android where reading / writing to the file system can be challenging without proper permissions, or without knowing the location of a temp directory.</p>
<p>For a client, specifying <code>caFile</code> can be used if connecting to a server that uses a self-signed cert, or when using a custom CA in an internal environment.</p>
<p>For a server, specifying <code>caFile</code> implies that:
1. You require clients to present a certificate