[openssl-users] Find size of available data prior to ssl_read

[counterpoint]

Thanks, that makes sense. My ability to optimise is constrained - the system
is a product so I do not know what the actual pattern of usage will be. But
there is a limit on buffer size within the system. It's a defined symbol, so
can be altered from the default of 32 KB, but only by recompiling the
system. I rely on a working assumption that people who change definitions
and recompile know what they're doing.

The system is threaded, but it is designed to operate with a relatively
small number of highly active threads, so grabbing 32 KB on the stack for a
short period shouldn't be too much of an issue. It would be much harder to
figure out the actual message size because the calls to SSL are taking place
in a generic core, whereas the protocol is in a different layer of code.
There are ways it could be done, but I'm inclined to leave that for a future
optimisation.

That leaves me feeling that the fixed buffer on the stack is the cleanest
solution, involving simple code. The copying overhead is there, but looks
hard to eliminate, and as you say there is plenty of other overhead. I'm not
sure that the small initial buffer offers me much gain, although it might
help in some situations. (Personally I'm inclined to use SSH tunnels rather
than SSL for SQL traffic, but that's another story!).

One remaining point leaves me uncertain. Supposing an SSL write gets the
response SSL_ERROR_WANT_READ. Then there is a POLLIN event. I take it the
first thing that must happen is a retry of the write. Assuming that works,
do I need to assume that there could be data to be read?  Or will a further
event occur, so that I should return to looking out for events?  I guess the
answer to the last question is probably no, but am unsure.





--
View this message in context: http://openssl.6102.n7.nabble.com/Find-size-of-available-data-prior-to-ssl-read-tp61722p61741.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.