On Mon, Nov 29, 1999 at 10:58:06AM -0800, Dan Kegel wrote:
> When I write networking code, I try to strictly separate protocol
> processing from I/O. That way the caller can use any style of I/O
> he likes -- synchronous, asynchronous, whatever; my protocol code
> doesn't care.
> BIO appears to have been an attempt to layer nicely, but judging
> by the comments here, it seems to have failed. Makes me sad.
For more flexibility, I created BIO pairs some time ago which can be
used to create sort of a pipe from the SSL library, where SSL_write
and SSL_read are used at one end of it (for plaintext data) and
BIO_read and BIO_write at the other end (to obtain the SSL/TLS
protocol data that the SSL library wants to be sent over the network,
and to transfer data from the network to the SSL library when the
library wants to read from the network). This leads to another layer
of buffering and thus increases virtual memory usage (encryption and
hasing are slow enough that we probably don't have to worry about the
extra processor cycles spent on copying around data), but it gives you
control over the actual I/O. (Example code for using BIO pairs can be
found at <URL:ftp://ftp.lavielle.com/pub%2fcl-https;type=d>; beware --
it's written in Lisp, and it uses features of a particular Lisp
implementation for which no publicly available documentation exists
yet.) Also you can always write your own BIO module if the
existing ones don't quite do what you need.
>> In any case, note that you probably don't want to handle multiple
>> concurrent connections in the same thread because public-key
>> computations can be quite time-consuming, and you'd stop all other
>> connections while computing a RSA signature for just one.
> Just how long do the computations take, and how often do they happen?
You have just two or so public-key computations per session (the exact
number depends on the ciphersuite); the time they take depends on
key-length. "openssl speed" will tell you (among lots of other data)
how many 1024-bit RSA signatures your machine can compute per second.
> My messages are rather small, and my connections stay open
> a very long time, so I'm hoping that the only step that's slow
> like that happens when a new connection is established.
> Is that the case?
Yes, but be aware that peers may initiate a new session on an
exisiting connection whenever they feel like it; this may allow
for denial of service attacks.
> If so, I might be able to have a worker thread do the slow bit --
> assuming the code is structured right (something I don't take
> for granted).
Each SSL structure should be handled by just a single thread at a
time, but there's no problem to assign the structure to different
threads during its lifetime. Just make sure that your programs knows
when the SSL structure is owned by a worker thread, and when it is
owned by the main thread.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
