Hi,
(this is an updated question, re-posted because I'm stuck and
scared.)
I've implemented a dual thread socket event pump that uses
OpenSSL for security - I'm doing all socket management.
I get a connection request, I accept the socket. Then I
call SSL_accept() on the socket and note whether WANT_READ
or WANT_WRITE. Next time I get an event on the socket, I
I call SSL_accept(), ad finitum. The problem, which happens
only occassionally, and only when the host system is under
stress, is that this process may fail because (it appears)
SSL stops reading from the socket, despite the fact that
SSL_accept() told me WANT_READ and ioctl with FIONREAD
tells me there are 51 bytes sitting to be read! This sends
my select() thread into overdrive because the untouched
data triggers select() immediately (and continuously).
Ouch.
My question is: why isn't SSL guaranteed to read from the
socket if there are bytes available? If I have no way of
knowing whether or not it took the data (other than the
dubious ioctl/FIONREAD call) how can I know whether I
should add it back into my select fd_set? Especially
since there seems to be times that this behaviour (leaving
data on the socket) is normal for OpenSSL - if I get
an 8K chunk on the socket, SSL_read() will extract the
smaller ~300 byte packets one at a time but ioctl reports
that SSL does not take any bytes off the socket until the
entire 8K have been decrypted, some N SSL_reads down the
road - I'm confused how it does this. Or perhaps my
system's ioctl/FIONREAD doesn't work properly? Yet the
results (select() returning instantly on that socket)
indicate this is actually what's happening.
Further odd behaviour is that SSL may _eventually_ take
the data, perhaps after spinning 400 times on it - what's
the deal? Is it because the coveted 52nd byte came in?
Finally, there is a case where SSL_accept() returns success,
but directly thereafter there are 51 bytes waiting on the
socket that SSL_read() now refuses to take! Argh! You
can imagine the results.
I'm using version 0.9.6 with win32/MSVC++. I compiled the
openssl DLLs with dynamic linkage to the multithreaded
runtime libraries just as I do in my main project, so there
should be no evil library mixing problems. I use one
sslContext for all connections, and one sslSession per
socket of course. BTW, my socket code, operating in
insecure mode (without SSL) works quite well; I can run
2000 actively talking sockets between a client and a
server with no breakdown. I *can* run 1000 secure sockets,
but only if I connect them slowly enough to avoid the
wicked non-read problem, which only seems to happen
detrimentally during SSL setup.
I'm a newbie at this SSL - I've got it almost running but
this stuff will kill me if I don't fix it - any help is
appreciated. Sorry for the verbosity of the post -
congrats if you made it this far ;\
Thanks,
Quick
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
