You're using blocking sockets, right ?
I had the same problem with NewPKI, here how I solved it:
ADMIN_REQUEST * SockServerADMIN::ReadRequest(BIO * ssl_bio, SOCKET hSocket)
{
ADMIN_REQUEST * req;
fd_set rfds;
struct timeval tv;
int sockt_state;
do
{
FD_ZERO(&rfds);
FD_SET(hSocket, &rfds);
tv.tv_sec = 0;
tv.tv_usec = 100;
sockt_state = select(hSocket + 1, &rfds, NULL, NULL, &tv);
}
while(sockt_state == 0 && !ShouldStop());
// Where we asked to stop or was there an error ?
if(ShouldStop() || sockt_state != 1)
{
return NULL;
}
req = d2i_ADMIN_REQUEST_bio(ssl_bio, NULL);
return req;
}
You just need to convert the BIO to a SSL handle, and do your SSL_read
instead of d2i_ADMIN_REQUEST_bio.
ssl_bio is a BIO created like this:
SSL_set_fd(ssl, connection);
if(BIO_set_ssl(ssl_bio, ssl, BIO_CLOSE) <= 0)
connection is the SOCKET returned by "accept".
Usually SO_KEEPALIVE is not a good idea, when you have many connections it
might take a lot of bandwidth.
Most socket gurus strongly unadvise to use it.
Frédéric Giudicelli
http://www.newpki.org
----- Original Message -----
From: "Joseph Bruni" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 06, 2004 3:51 AM
Subject: Re: OpenSSL: threading question
I'm glad this discussion happened about now. I, too, am implementing a
query/response system and I've been thinking about putting the read and
write cycles into different threads.
My reason for wanting to do this would be to allow the server, which
sends the initial message, waits for a response to move on to the next
message. If I did this in a single thread, everything would work fine.
My only concern was to be able to handle the case were the "client"
closed the connection when there were no more messages pending. Since
the server only does an SSL_read after sending a message, it would
never receive the close-notify until another message became available.
For some clients, the time between messages might be days.
Since I need to detect dead clients, I considered the use of
keep-alives. This would give me a write/read cycle that should reap a
close-notify if one is pending.
My other thought (which has been dashed to pieces with this discussion
thread) was to have a single global reader thread to receive potential
close-notifies.
Since my message server will have potentially thousands of simultaneous
connections, the last thing I want to do is switch to a
non-blocking/polling style. (I would prefer a lot of threads blocked on
I/O than a few threads spinning in circles.)
Any suggestions?
On Jan 5, 2004, at 5:22 PM, Frédéric Giudicelli wrote:
> Right on !
>
> May I ask a silly question?
> Why would you do such a weird thing in the first place? (maybe we
> should
> have started from there) :)
>
> Frédéric Giudicelli
> http://www.newpki.org
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
