Thank you again David, It seems that now I understand all the crash scenarios and my server can deal with them correctly. Thank you for your guidance.
As for the network issue scenarios here are some details about the last case: 1)The server is running on UNIX, the client is running on windows or unix. unplug the client or the server. The server does not report anything! it does not detect that its connection to the client is lost... SSL_read is not even called because my select does not detect any change on the socket.... This surprised me. 2)The server is running on windows, the client is either on windows or on unix. 2.1)unplug the server. It reports ECONNRESET. This is probably the bug you are talking about. How should I go about checking the interface here? any specific APIs to use? my server is in C/C++. Thanks. 2.2)unplug the client. My server reports nothing, similar to 1). This again surprised me but I am by no means an expert on sockets. While I can work around 2.1) by checking the interface as you suggested, I am at loss with 2.2) and 1). Because now my server has a situation where clients are no longer connected but it does not even know it... My server does a select on each client socket to wait for incoming messages, so I was hoping that a network disconnection is also an information that the select should detect but apparently this is not the case... Is there a way my server can be notified? if not, is there a way my server can proactively look for such clients? I am concerned about my server CPU usage in case they are too many disconnected clients... The reason I need all of this is that my server is using some important resources for each client. If a client connects then there is a network issue, the client might have finished its work, exited, but the server is still using the resources... Thanks again for all your help. On Tue, Nov 4, 2008 at 8:37 PM, David Schwartz <[EMAIL PROTECTED]> wrote: > > > Thanks David. > > > Unfortunately option 1) and 3) are not possible for my clients. > > In other words, you cannot engineer a sensible option and have to fake it. > That's fine, but solutions that aren't engineered tend to be poor. > > > option 2) seems the way to go for me, but so far it proved unreliable. > > That was the downside of that option. > > > Here are some scenarios I have been playing with: > > > 1)Crash a client running on unix: > > > The SSL_read returns 0 . The SSL error code is > > SSL_ERROR_SYSCALL [An SSL I/O error occurred]. The errno is 0! > > Seems reasonable. No unread data was pending, so the TCP connection closed > normally. > > You would definitely infer a crash in this case. Network failures don't > normally close connections. > > > 2)Crash a client running on windows: > > > The SSL_read returns -1 . The SSL error code is SSL_ERROR_SYSCALL > > [An SSL I/O error occurred]. The errno is ECONNRESET > > [Connection reset by peer] > > So there was some pending unread data in this case. You would definitely > infer a crash in this case. A network failure won't reset a connection, but > a rebooting host might. So you can't be sure the client didn't crash. > > > 3)Leave the client running on unix or on windows and unplug the network: > > > The SSL_read returns -1 . The SSL error code is SSL_ERROR_SYSCALL > > [An SSL I/O error occurred]. > > The errno is ECONNRESET [Connection reset by peer] > > Did you unplug the client or server? Was the server running Windows? You > need to explain this case in detail. If you unplugged the *server* > interface, then that's a very unusual special case that you need to > specifically test for by checking the interface. (Due to an unfortunate > Windows bug. It reports ECONNRESET when it loses a network interface even > though the connection was *not* reset by the peer.) > > > As you can see this does not seem to be reliable to distinguish > > between what really happened. > > The first two cases seem perfectly sensible. You didn't explain the third > case in early enough detail for me to comment on it. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
