> > 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. That the native sockets API supports concurrent access to the same object from different threads is an exception. The norm is that you must protect an object with a mutex or similar if you want to access it concurrently from multiple threads. > 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). I can't quite completely follow you, but if your question is "how can I fix broken code that I can't change", the answer is that you can't. Perhaps you want to use a separate thread or threads connected to a bidirectional pipe and let the existing code make blocking reads/writes to that bidirectional pipe. Then those threads can proxy from the pipe to an SSL connection. If existing multithreaded code has built-in calls to SSL_read/SSL_write that don't correctly respect OpenSSL's locking model, then that code is broken and your best bet is probably not to use it. Do the SSL part yourself. > > 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. How do you handle the case where the 'write' takes way too long? OpenSSL supports multithreading the same way most libraries do. It doesn't permit concurrent access to the same object from multiple threads without user-supplied locking. This is how almost every library works. > 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. No. I don't like blocking sockets because it's very hard to get them right. Again, what do you do if one thread calls 'write' and the 'write' blocks for a very long time? Do you call 'shutdown' in another thread? Do you try to interrupt the 'write' with a signal? Bluntly, blocking sockets is done wrong more often than it's done right. And you wind up ripping your hair out trying to get the edge cases right. It may work fine when things are really simple, but as soon you need to do something at all complex, things start breaking. I'm still not sure I understand the situation you are in, so I'm not sure I'm giving you the right advice. If the code has built-in support for OpenSSL, but that support has broken locking, just don't use that support. Use your own code to proxy the plaintext to/from an SSL connection. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
