|
|
On Sun, 29 May 2005, Andrew Tridgell wrote:
2) it wasn't at all obvious to me how to use the openssl api in an
event driven non-blocking framework like smbd. Maybe it can be
done, but it wasn't obvious to me.
Using OpenSSL in a non-blocking framework isn't much of an issue. If the
transport is non-blocking so is OpenSSL. But the event framework used may
need a little more argumentation than normal descriptor I/O due to the
layered transport nature of SSL.
a) An SSL connection may have data pending in memory from a previous
call, so don't blindly rely on transport event notification alone.
b) An SSL operation may require events of the opposite nature to
complete. SSL_read may need an write event and SSL_write may need a read
event to complete. This is indicated by the SSL_ERROR_WANT_xxx soft error
codes. When these errors is seen one simply retries the SSL operation
after the suitable event has happened. The same data should be used on the
retried operatios.
Both usually falls quite nicely into place if one relies on the error
codes alone to determine when to wait for a transport event and what kind
of event to wait for. If you haven't seen an SSL_ERROR_WANT_xxx then
assume the SSL is ready immediately for the operation in question.
What it doesn't support is non-blocking crypto offload to a crypto CPU,
but I don't see this being a big issue for Samba.
If you want your own network I/O layer for the actual I/O operations then
a custom BIO layer is needed. But in most cases this should not be needed.
Due to the event requirements it is usually better to push OpenSSL to the
edge of the framework as a low-level IO/Transport method if your framework
consists of both event notification and the actual I/O operations.
Regards
Henrik
|
|