On Mon, Nov 06, 2006, kalikali wrote:
> I know this is developer's mailing list (i've tried user's mailing list but
> without success) but to solve my problem i need someone with knowledge of
> OpenSSL internals. I suppose that openSSL is not as windows compatibile as
> it is advertised to be. I try express what I mean in several points:
>
> 1.My application sends and recives messages from the same socket and writing
> is separated from reading (there is no relation between). Application should
> wait in blocking function till there will be some data to send or to
> receive.
>
> 2.From OpenSSL FAQ: "...SSL connection may not concurrently be used by
> multiple threads.." This means that openSSL commands cannot be used
> simultaneously from different threads as native socket API can be.
> Preferable way to deal with it is using non-blocking sockets. There is
> example in openSSL source tree: 's_client.c' but unfortunately it works good
> only in unix environment ('select' function can wait for socket and user
> event at the same time (it can use pipes)). Unfortunately 'select' in MS
> windows can listen for events only from the same provider (you cannot mix
> socket's , pipes's , or console's handles in the same 'select') - to
> overcome this issue, event polling (timeouts) is used in 's_client.c'.
>
> 3.Polling is good for testing but not for real application. MS windows has
> some special mechanism to deal with waiting for user and socket events
> simultaneously, i mean 'WSAEventSelect', WSAAsyncSelect'. And this is the
> where my problem begins.
>
> 4.I use 'WSAEventSelect'. Windows assumes that writing to socket is possible
> all the time, so you don't have to check socket's possibilty to write if you
> want to write, like you do it using 'select' statement. Only if 'send' will
> fail with WSAEWOULDBLOCK error code windows will send FD_WRITE event to your
> application if writing will become possible, if 'send' will fail from other
> reson, FD_WRITE will NOT be sent.
>
> 5.But i'm using openSSL, not winsock API. When 'SSL_write' fails with
> 'SSL_ERROR_WANT_WRITE' error code i have a little problem... 'SSL_write'
> doesn't tell me why it has failed, 'SSL_ERROR_WANT_WRITE' means only that i
> have to repeat this operation. If 'SSL_write' has failed due to 'send'
> command which has returned WSAEWOULDBLOCK i can safely wait in blocking
> function till 'FD_WRITE' event will be sent by OS. But if 'SSL_write' has
> failed from other reason I will stick in deadlock because 'FD_WRITE' will
> not be sent even if writing to socket will become possible.
>
> 6.I have dug openSSL source a little, and i've found BIO_write can fail for
> many reasons with the same error code projected to user.(See
> 'BIO_sock_non_fatal_error' function in 'bss_sock.c' file in openSSL source -
> WSAEWOULDBLOCK is one from many options in 'case' construction). So if
> 'SSL_write' will fail from BIO error I have no guarantee that it was
> WSAEWOULDBLOCK (maybe 'SSL_write' can fail also with 'SSL_ERROR_WANT_WRITE'
> without BIO error but from it's internal logic - i don't known, i'm not
> openSSL developer). That's why I suppose that openSSL is not exactly windows
> compatibile.
>
>
> So my questions is: Is openSSL real compatibile with MS windows?How 'WSAXXX'
> framework should be used with openSSL? Can someone give me some example?
>
I have never come across a report of a deadlock in that situation and several
applications have reported using WSAEventSelect() in the past. There are
several possible reasons...
1. The application works because of the feature mentioned in KB186245.
2. The send() function never returns any of the other BIO_sock_non_fatal_error
codes so this is not an issue in practice. The documentation seems to suggest
this but that's no guarantee.
3. Applications take additional steps before calling WSAEventSelect() to
ensure the socket is not writeable.
Option #3 might include...
Call select() with a zero second timeout. If it indicates socket is
writable retry the opertion, if not call WSAEventSelect().
Call WSAGetLastError() to confirm the error code.
If neither of these is acceptable there are two other options.
One is to write a custom socket BIO. In this case it would be very simple
because it would copy all the existing methods *except* the write behaviour
which would set the retry flag only if the error is WSAEWOULDBLOCK.
The second alternative is BIO pairs this give an application total flexibility
on all socket I/O but is more complex to handle.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
