> 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.
I've tried to explain this to you until I'm blue in the face, but you just don't seem to get it. When you call SSL_write in a non-blocking fashion, and it fails, it will not succeed until something changes. If you try it again, it will fail again (unless something changed in the instant between the two calls). One possible thing that could change is the socket could become writable if it wasn't writable before. Now, there are two cases: 1) SSL_write didn't fail a write anyway, so the operation will still fail. In this case you won't get an FD_WRITE event (because SSL_write never called write), but one wouldn't help you anyway. 2) SSL_write did fail on the write, and the operation will now succeed. In this case, you will get an FD_WRITE event, or your event will unblock. In case 1, it may be that receiving data will allow the SSL_write to succeed. So you need to arrange to retry the write if that happens. An easy way to rig this to happen using WSAEventSelect (which is what I recall you were using) is to have the read thread unblock the write event if it detects that the socket is readable. (Just in case the read event made an SSL_write possible.) If you don't want to do that, you can switch to BIO pairs and this problem goes away. With BIO pairs, you manage the socket directly, so you know whether a 'write' failed with a WSAEWOULDBLOCK. (However, you still have to retry a failed write if anything changes, whether that's data that's been received or you are now able to send data.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
