> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of counterpoint > Sent: Thursday, December 17, 2015 04:51 > > Although maybe the simple answer is to read into a temporary 32 KB buffer and > then malloc and copy.
That, more or less, was my recommendation in my previous post. The optimal size of the temporary buffer depends on factors we don't know. If most of your messages fit in 32KB, then that may save you extra calls to SSL_read. On the other hand, it could mean excessive copying - it might be better to use a smaller buffer to reduce the size of the additional copy operation, even at the cost of an extra call to SSL_read. (Obviously some copying is happening in the SSL/TLS processing anyway, and the cost of such copying is small relative to the cost of decryption and other compute-intensive operations. But if your application deals with a high transaction rate then cutting down that extra copy may be worthwhile anyway.) If your application is single-threaded, you can make that a static buffer; if not, it needs to go on the stack, which could be a problem if your threads are stack-constrained. That's another argument (if it applies to your case) for using a smaller initial buffer. If the first chunk of your message tells you how large the entire message will be, then this approach means only one call to the allocator per message received, which is good. And it means the same code path for every message regardless of size, which is good for program correctness and maintainability. Based on what you've told us, this is the approach I'd recommend. The only question is the size of that initial buffer, and you're in a better position to determine that. -- Michael Wojcik Technology Specialist, Micro Focus _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
