1

(3 replies, posted in wolfSSL)

Chris,

Thanks a lot for such a detailed and well written answers. Such a pleasure to read!

We are working on a video streaming application where web-based secure websockets (wss)
receive video chunks from our server. So we are adding the wolfSSL to our server.
As said before, we are using callbacks for reading and writing, and trying to avoid any extra copying of data,
so being able to send out straight from your output buffer is very important.

So far it works very well, but we need to test for performance, memory leaks, etc..., with multiple concurrrent websocket sessions. Our server runs on Windows, but still we want the minimal impact on the binary size.

2

(3 replies, posted in wolfSSL)

Hello,

Right after the download of wolfssl-3.9.0, I opened wolfssl.sln with Visual Studio 2008, didn't change anything and compiled.

Release build resulted in wolfssl.lib of 2Mb size!
Strangely, Debug build produced wolfssl.lib of 1.7MB.

When I linked my executable with Release wolfssl.lib, my .exe added 200Kb of size.

From what I read in the forums, the sizes (even without defining features out) should be much smaller.

Any ideas, please?

3

(1 replies, posted in wolfSSL)

Hello,

I have read everything I could and still don't have an exact understanding:

If the clients are browsers creating secure websockets (wss) to connect to our server, then
do we need to call
wolfSSL_CTX_load_verify_locations(m_pWolfCtx, "..\\ca-cert.pem", 0);
in our server initialization code?

1. We don't need to verify client certificates, so the above call is not needed. Is that correct?

2. If we do need to verify client certificates, what else needs to be done on the server side, besides the call to wolfSSL_CTX_load_verify_locations?

Hello and thanks for your work on wolfSSL!

I have one suggestion for your current code:
in the internal.c file
SendBuffered method ends with these 3 lines:

    if (ssl->buffers.outputBuffer.dynamicFlag)
         ShrinkOutputBuffer(ssl);

    return 0;

It looks like shrinking the output buffer here is not a best idea here; I just commented out these two lines:

    if (ssl->buffers.outputBuffer.dynamicFlag)
         ShrinkOutputBuffer(ssl);

and got much better performance.

What you are doing right now is allocating and deleting the output buffer on every write operation. When commenting out these two lines, you will only delete and allocate when your new write needs a bigger buffer than you already have. Good optimization. This is helpful when you are sending out variable-size chunks. Also, it allows us to send directly from your output buffer (we are using callbacks, of course, for reading and for writing, because we use overlapped socket IO with completion ports). With the current code one must copy from your output buffer to his own buffer inside of his write callback.

Hope this makes sense to you and please correct me if I am wrong.

Dude 777