On Mon, Nov 29, 1999 at 10:40:28AM +0000, Geoff Thorpe wrote:
> On Fri, 26 Nov 1999, Bodo Moeller wrote:
>> [...] I'm still not convinced that s_client and s_server
>> are correct w.r.t. handling non-blocking I/O (the problem is that when
>> the peer starts renegotiation, one may have to wait for readable data
>> at the socket to be able to do SSL_write, and for the possibility to
>> write data to be able to do SSL_read; s_client and s_server may happen
>> to do the right thing, but they're too unreadable to make sure).
> 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).
> 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"?
>> 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.
> 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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
