> I'm not checking socket's possibility to write, i'm just issuing > SSL_write command till SSL_write will return > SSL_ERROR_WANT_WRITE. Now, what?
Retry the write when anything changes. That would include receiving an FD_WRITE event. > On unix i can use 'select' with socket handle as input in write > set. It will return when writing will become possible. But on > windows it's not such easy... Please, here you have fragment from > windows help: > > "...The FD_WRITE network event is handled slightly differently. > An FD_WRITE network event is recorded when a socket is first > connected with connect/WSAConnect or accepted with > accept/WSAAccept, and then after a send fails with WSAEWOULDBLOCK > and buffer space becomes available. Therefore, an application can > assume that sends are possible starting from the first FD_WRITE > network event setting and lasting until a send returns > WSAEWOULDBLOCK. After such a failure the application will find > out that sends are again possible when an FD_WRITE network event > is recorded and the associated event object is set...." > it means that that i can issue 'send' commands till it will > return WSAEWOULDBLOCK, then i can safely assiociate FD_WRITE > option with my event object and wait in 'WaitForMultipleObjects' > till windows will signal this event.(writing will become again possible). Right. > But i'm not using native winsocks API, i'm using openSSL. OpenSSL > issues 'sends' commands internally. When i issue SSL_write, i > don't known how many times openSSL issues 'send' command and what > is return value of 'send'. The only thing i will get is > SSL_ERROR_WANT_WRITE. (It could, but it don't have to (!!!!) be > result of WSAEWOULDBLOCK 'send' error, it could be result of > other errors or some openSSL internal logic). See: > 'BIO_sock_non_fatal_error' function in 'bss_sock.c' in openSSL > source tree. It doesn't matter what caused the error. Whatever it is will only go away when something changes. There is no way that something can change without you knowing about it. Nothing is going to change until or unless the socket changes state or you make some call into OpenSSL. > In simply words: 'select' returns current possibility of socket > to do something, windows events are results of some other events > not current socket's states. I cannot simply wait for some > condition to become possible i should know if i have to wait, > openSSL breaks this logic: it doesn't do everything not bothering > user, but it also takes away control from user over issuing > winsock commands. You can wait for something to change. If nothing ever changes, the write will continue to fail. SSL_ERROR_WANT_WRITE is OpenSSL's way of saying that something has to change. > I have an idea (now just only idea) of how it could be overcome > but this is my own idea and i have to test it (mix windows events > with 'select' in some special way). But what is the sense of > sending questions i answer to it my own? I think OpenSSL is not > such windows compatibile as it's advertised to be. You are making things really complex. If you want complete control over I/O, use BIO pairs. >> The beauty of non-blocking operations is it's perfectly safe to >> retry every operation anytime anything changes. So you have to do >> something really dumb to deadlock. > No comments. But that's the trick. If you are trying to do two things (say, read and write), just retry both any time anything changes. If you cannot make any forward progress, something will have to change before you can make forward progress. So when something changes, retry everything. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
