> > This won't work for a variety of reasons. One is that an SSL_write may fail > because of a negotiation in progress and being able to *read* data from the > socket may allow the write to progress. >
Even in my dreams I didn't imagined that you have try to compile it. Of course it won't work!!! That's why i put this: ...arguments to functions are not exactly as in real implementation and some function are simplifed versions of real one, some functions are omitted... and this: <--- PSEUDO CODE --------> and datailed description how it works in my previous post. In this piece of pseudo code, i have tried to show what will happen if SSL_write will return 'SSL_ERROR_WANT_WRITE'. It's only a little part of what complete procedure should deal with (but if one part doesn't work, whole procedure is worth nothing). (There is one bug in this pseudo code, I mean: in case SSL_ERROR_WANT_WRITE: There should be WaitOnWrite = true; not WaitOnWrite = false; but you probably have assumed that.) Again, this pseudo code was only to show one thing. I haven't imagined that you start to optimize it. The most important part not included in this pseudo code is one for reading from the same connection to another user buffer. It should work exactly the same like for example 's_client.c' in OpenSSL soure tree but in windows environment. >I would suggest some changes to this loop that should solve your problems: > > 1) Protect all SSL_read/SSL_write functions with a mutex (per-connection if > you want). This will prevent you from calling SSL_read an SSL_write at the > same time for the same connection. It will also allow you to synchronize your > handling of cases where you need to wait. > Really you can give me tons of good advices, but it will be worth nothing if in any line of your advice you say this: > Again, the short version is this: Anytime anything changes, retry all > >operations that were waiting for something. > You are doing everything except trying to understand that your knowlage about something has changed comes from windows, and windows notifies you about it in special cases. It is possible that something will change and windows won't notify you. You have to know about it before you block in wait function. Windows sends FD_WRITE event if writing is possible and previous invokation of 'send' has failed with WSAEWOULDBLOCK code (only this code, if it has failed from other reason, FD_WRITE will not be send and waiting for it will cause deadlock)... What words should i use, you will understand this?! Nevermind, i cut this thread ,forget about everything, this is my last post, don't answer to it... Lucas ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
