Thanks David.

>The deadlock scenario can only occur when you refuse to call SSL_read until
>you find the socket in the read set from select. So you must be careful
>under what circumstances you decide to get into this state.

So under which circumstances should an SSL_read be performed on a socket? My
list is currently:
* The socket is readable via select()
* The socket returned WANT_READ from a previous SSL_read or SSL_write
operation
* Should I call SSL_pending on the instance instead and use this as a flag
to see if data is available? Is this resource intensive etc?

Is that all I need to worry about/is it correct to know when a read should
be performed? If you could tick or cross (or add!) those ideas that would be
great.

I am still a bit unclear on how you respond to a WANT_READ/WANT_WRITE error;
as you mention select()ing the socket as well as then performing an SSL_read
(but never an SSL_write) in response to it.

Here's some pseudo code to represent the logic I am thinking of at the
moment in response to the possible scenarios:

// Receiving WANT_READ during an SSL_write
bool writeSuccess = false;
while (!writeSuccess) {
        ret = SSL_write(...)

        if (ssl_Error(ret) == SSL_ERROR_WANT_WRITE) { 
                // Wants a write, just re-try the operation.
                Continue;
        }

        if (ssl_Error(ret) == SSL_ERROR_WANT_READ) {
                // Socket requires it be readable prior to performing the
write.
                // Block until the socket is readable
                Select(socket, readfds);

                // Socket is readable by now, re-try the SSL_write
                // without needing to call SSL_read
                continue;
        }
        ...
}

// Receiving WANT_READ during an SSL_read
while (true) {
        ret = SSL_read(...)

        if (ssl_Error(ret) == SSL_ERROR_WANT_READ) {
                // Re-try the SSL_read
                continue;
        }

        if (ssl_Error(ret) == SSL_ERROR_WANT_WRITE) {
                // Socket wants to be writable before reading
                // Block until the socket is writable
                select(socket, writefds);
                
                // Socket is writable by now, re-try
                // the read without needing to call SSL_write
                continue;
        }
        ...
}

Can you please comment on the above pseudo code to see whether this logic is
correct? Of importance is the way I would just have the read/write process
block (should I block?) on select() until the socket is readable/writable,
and when it is as per the error message, run the SSL_read/SSL_write process
again.

Thanks,
Andrew

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Friday, 18 May 2007 6:20 AM
To: [email protected]
Subject: RE: Multi-threaded SSL Socket Usage


> So long as your last operation, SSL_read or SSL_write, returned WANT_READ,
> there is no reason to retry that particular operation until you find the
> socket in the read set.

        Ack! Sorry part was badly worded. There is no reason to retry that
particular operation until you either find the socket in the read set or
perform some other operation that might read from the socket.

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [email protected]
Automated List Manager                           [EMAIL PROTECTED]


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [email protected]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to