Hi,
On Mon, 29 Nov 1999, Bodo Moeller wrote:
> On Mon, Nov 29, 1999 at 10:40:28AM +0000, Geoff Thorpe wrote:
> > The easiest way to do this is
> > (i) select on readability, and writeability only if there's data waiting
> > to go.
> > (ii) read everything that can read.
> > (iii) grind the SSL state-machine
> > (iv) write anything that can write and has something waiting to go.
> > (v) gring the SSL state-machine again.
> > (vi) go back to (i)
>
> How do you define the condition in (i) ("if there's data waiting to
> go")? If you only select for writeability when your _application_
> tries to write data, then you could be in trouble when the peer
> initiates a new handshake, so that the SSL library may want to write
> data over the network in SSL_read. If you correctly watch the results
> of SSL_get_error after each I/O operation, then things are relatively
> easy (there's a complication when doing non-blocking _bi-directional_
> I/O, in this case you have to watch BIO_number_read and
> BIO_number_written on the underlying socket BIO to detect whether the
> calls to SSL_read and SSL_write actually did something or whether
> there was no progress at all; at least that's how I solved the
> problem, it cannot be solved solely with the existing SSL API).
Well I didn't mean to imply that the above model would work with the
standard "plug the socket BIOs into the SSL" approach. You seem to have
assumed when I said "writeability" I meant only on the "clean" end because
OpenSSL apps typically use socket BIOs in the SSL to go straight to the
network on the "dirty" end.
I've got a "proxy" state machine that deals with incoming and outgoing
buffers on at both ends of the chain ... hence if there's data in an
outgoing buffer, select for writeability. I've completely detached the SSL
from the networking - on the outside I'm running the buffers and the
networking (selects, etc), on the inside I'm throwing data in and out of
the SSL from both sides myself. I only briefly thought of using (or
writing) BIOs for this, but had already been unhappy with some of the
black magic in the code and when I looked further, I liked it even less.
So I'm cutting my own and letting OpenSSL worry about just the SSL
protocol itself.
>
> > I abandoned BIOs a while ago (where possible that is) and have my own
> > comms/buffering wrapper so this is the way that works for me. The last
> > recollection I have of s_client/s_server is some seriously mutated
> > handling of stdin/stdout with the raw socket that was almost written the
> > way it was as some sick exam question.
>
> What do you mean by "stdin/stdout"?
The ugly loop that is reading and writing from stdin/stdout and then
reading and writing to the socket. I guess to some degree that complexity
is necessary when not using NBIO but it sure is opaque the way it's
written - and given that one of it's main uses is supposed to be as an
instructive guide to programmers ... well, I don't think "mutated" was
such an inappropriate word.
> > Unless you send the RSA operations off to a distinct process/service and
> > communicate with it via the same non-blocking IO machinery as the one
> > being used to conduct the SSL proxying. Non-blocking in one thread will
> > usually beat threading ... until you block on a mod_exp. :-)
>
> Of course the library could be modified to be more friendly to
> single-threaded non-blocking servers (e.g. by allowing mod_exp and
> functions that use it to be run in multiple slices, so that other
> things can be done inbetween), but with the library as it is now
> this is not possible.
That's not what I mean ... I mean that the single-threaded server can
communicate using NBIO to a distinct process/service and ask *that* to
perform the mod_exp operation and send the result back down the
socket/pipe/whatever. Kind of like using hardware crypto but just across a
process boundary instead of a physical one. The original single-threaded
server can get on with other business and when the mod_exp result comes
back through the socket/pipe/whatever, the next select will let it know.
Cheers,
Geoff
----------------------------------------------------------------------
Geoff Thorpe Email: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europe http://www.int.c2.net
----------------------------------------------------------------------
May I just take this opportunity to say that of all the people I have
EVER emailed, you are definitely one of them.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
