Hello,
> >You may use select() but with some care.
> >Simplest way is to:
> > 1) wait on select()
> > 2) read hit from SSL descriptor occur
> > 3) read incrementally with SSL_read() from that descriptor until
> >WANT_READ
> > (or in other words - get all data from SSL read buffer)
> > 4) go to select()
> >
> >In 3) you may get WANT_WRITE too, in this case you should go
> to select()
> >and wait for write hit on SSL descriptor and perform 3) as you
> >do when you get read hit in select() on this SSL descriptor.
>
> Are you suggesting that the write hit from select is an
> indication that the descriptor is writable and hence the data
> that SSL required to write before it could serve our read
> request must have been written.
Yes.
> And so we would expect a
> successful SSL_read after this write hit from select?
Depends what "successful" means.
If, from last SSL_read() we have got WANT_WRITE then this means
that before reading application data some SSL protocol data
must be written (renegotiation packet, non critical alert packet, ...).
This requires writable socket, so we waiting when socket is writable ...
.... and from select() we get such hint ...
.... so we call SSL_read() again ...
.... now SSL layer write some protocol data to peer ...
.... maybe read some protocol data from peer ...
.... lets assume that this ends successfully ...
.... now SSL tries to read some application data ...
.... if in TCP buffers is SSL application record ready to decrypt ...
.... (which means full record) ...
.... this record is decrypted ...
.... and some data is returned to SSL_read() caller ...
.... if there is no SSL record ready ...
.... WANT_READ is returned to SSL_read() caller...
.... and caller may call select().
Some explanation of "some data is returned to SSL_read() caller":
Assume that SSL application record after decryption has 200 bytes.
If SSL_read() wants to get 110 bytes then 90 bytes will wait
in SSL read buffer. This call to SSL_read() will return 110
(number of bytes read from SSL buffer).
If we now go to select() then we may have deadlock because our
peer send us 200 bytes, we have still 90 to read but instead
of reading this bytes we waiting in select().
To resolve this problem we can call SSL_pending() before select()
to check if SSL buffers are empty or not, or call SSL_read()
until WANT_READ is returned.
For example (some pseudo-code :-):
- first SSL_read(s, buf, 110) = 110
- second SSL_read(s, buf+110, 110) = 90
- third SSL_read(s, buf+200, 110) = -1 + WANT_READ
and SSL bufers are empty, we have 200 bytes of data
and we can go to select().
Of course this is for non-blocking sockets.
Best regards,
--
Marek Marcola <[EMAIL PROTECTED]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
