First... sorry for trash in my post's subjects. I'm using www interface on my email provider site for sending emails and there is no option to change this. (I don't known if this is my mailbox or this mailing list server problem).
> Actually, it's extremely complicated. For example, what do you do if you > > call 'write' and it doesn't return in a reasonable amount of time? > > You cannot use 'select' with blocking sockets. If you do, and your 'write' > blocks (say because only a few bytes could be written at that instant), you > won't be able to call 'read'. > I don't known if it was your exact intention but you have suggested me some problem - that delay in sending packet could cause incoming buffer overflow due to not reading data by a long time, hence data loss. But this is the not problem of idea of blocking as a such but rather using mutexes with blocking sockets. In native socket API delaying in writing blocking socket has no impact on reading one. It is only problem with using mutexes for serializing data which should be done due to openssl non multithreading. I can use 'select' with blocking sockets, it will not block on incoming data even if there are not writing data. Of course, as you have said, a can't use it for reading because it will block. Using 'select' for signaling possible data is not prohibited.(it should be clarifying for other readers) > > So it works like this: > Well... this is not exactly solution to my problem. I have asked about blocking sockets in special context. I'm using opessl by delphi component which is intrinsic designed to work in true blocking mode (which is fine for native socket API, encrypted connection is additional option for it). What you have suggested is some kind of emulation which is rather usless in my case (SSL_read and SSL_write are hardcoded in component code in blocking mode - I thought rather about doing some openSSL API calls before invoking component socket read method, ensuring that the method will be invoked if there are some data on the socket causing it to not block). > Doesn't this kind of prove that your assumption (that non-blocking sockets > are more complicated) is wrong? Look at all the craziness you have >to go > through to get blocking sockets to work right. > Eeee.... I'm little bit surprising about your interpretation. I thought all the craziness that i have to deal with is due the fact that OpenSSL is not supporting multithreading. I don't blame anyone for this, maybe it is not as easy as someone who did't implemented this may think. I'm only trying to show my problem and find most suitable and easiest solution. I gain an impression (correct me if I'm wrong) that you are trying to compromise the idea of blocking sockets only because openSSL doesn't support it. Many people (like me) are using native socket API (in which blocking socket are natural and correct working) and suppose that openSSL API would be the same - that's why there are many problems with that.(additionaly, just like in my case, it is not only to change my thinking about using socket but also to change third party libraries). Anyway, thanks for your help David. Lucas ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
