RE: RE: Multithreading problem
> I am somewhat confused. Network Security with OpenSSL states quite > clearly that OpenSSL handles multithreading and blocking sockets > fine as long as you give it proper callbacks to acquire locks as > needed. If you go to the book's site and download the code examples > ( http://www.opensslbook.com/) it is examples 4-1 and 4-2. Have I > misread this in some way? Does the multithreading actually not > work as advertised? o_O > ~RMC It works fine and as advertised. However, it does not work precisely the same as native TCP does. The problem is when you have code that does a blocking operation in one thread and a concurrent operation in another thread on the same SSL session. The problem is that a blocking read, for example, might take a long time. At the same time, you might want to do several writes that would complete immediately. But you can't because the blocking read has to lock the SSL session. Unlike the normal case, native TCP does allow concurrent overlapping operations on the same object from multiple threads. You can have one thread block in 'read' for hours while another thread completes many 'write's instantaneously. If the thread blocked in 'read' held a lock on the connection, that wouldn't work. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: RE: Multithreading 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. 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RE: Multithreading problem
I am somewhat confused. Network Security with OpenSSL states quite clearly that OpenSSL handles multithreading and blocking sockets fine as long as you give it proper callbacks to acquire locks as needed. If you go to the book's site and download the code examples ( http://www.opensslbook.com/) it is examples 4-1 and 4-2. Have I misread this in some way? Does the multithreading actually not work as advertised? o_O~RMC On 10/20/06, kalikali <[EMAIL PROTECTED]> wrote: First... sorry for trash in my post's subjects. I'm using wwwinterface on my email provider site for sending emails and there isno option to change this. (I don't known if this is my mailbox or thismailing 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 someproblem - that delay in sending packet could cause incoming buffer overflowdue 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 aboutblocking sockets in special context. I'm using opessl by delphi componentwhich 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 uslessin my case (SSL_read and SSL_write are hardcoded in component code in blocking mode - I thought rather about doing some openSSL API calls beforeinvoking component socket read method, ensuring that the method will beinvoked 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 Listopenssl-users@openssl.orgAutomated List Manager [EMAIL PROTECTED]
RE: RE: Multithreading problem
I try to develop a client-server ( not WEB Base) using openssl. What the certificates do I need to load for my client and my server?. Assume that I am a ROOT CA, having root certificate and root private certificate. Please help. I think that my client needs client cert and private key. My server needs server cert and server private key. But I am not sure. Who sign my client/server certificates ( ROOT CA)? Root CA cer and ROOT private key need for client side ??? Thank You TD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kalikali Sent: Friday, October 20, 2006 9:57 To: openssl-users@openssl.org Subject: Re: RE: Multithreading problem > I am very, very new to openssl. There is a good example (Example 5-16, > Network Security with Openssl book)) for using nonblocking openssl. It > is easy to understand. It uses one thread to handle 2 nonblocking > socket. You may have to modify it to handle multithread. At least, you > have example to follow. I am trying to modify this example, so one > openssl socket is handled by one thread using select ( native API) to > monitor socket. > > Thao Dinh > Thanks Thao for suggestion. It is not only problems with writing correct code but also wish to use some components (which I have used for communication without encryption) forces me to raise this problem on this mailing list. But of course examples given by you should be useful for me (if i will implement this(probably i will heve to)). Lucas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RE: Multithreading problem
> I am very, very new to openssl. There is a good example (Example 5-16, > Network Security with Openssl book)) for using nonblocking openssl. It > is easy to understand. It uses one thread to handle 2 nonblocking > socket. You may have to modify it to handle multithread. At least, you > have example to follow. I am trying to modify this example, so one > openssl socket is handled by one thread using select ( native API) to > monitor socket. > > Thao Dinh > Thanks Thao for suggestion. It is not only problems with writing correct code but also wish to use some components (which I have used for communication without encryption) forces me to raise this problem on this mailing list. But of course examples given by you should be useful for me (if i will implement this(probably i will heve to)). Lucas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RE: Multithreading problem
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
