~RMC
On 10/20/06, kalikali <[EMAIL PROTECTED]> wrote:
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]
