Hi. I'm not an expert on the crypto side of things. It would seem that you need to detect that the other end isn't responding for some reason reason, not whether the client is up or not. This might include an improperly configured switch or router between the two starting to drop packets which would lead to both ends thinking the other is down, when both still work and both network interfaces don't show an error. In cases like this you would probably need to use a 'Heartbeat". Have both ends use an inactivity timer to send a periodic "I'm alive, are you?" message, and close the connection if there isn't a response. Actual data over the link can count as a response. You can use two connections, one with the data and one without, but the improperly configured router could be set to kill the heartbeat and not the data connection. What the implications are, with respect to having a predictable pattern in the connection message is in relation to making a known plaintext/crypto text, I'll leave to the experts. Or I may be misunderstanding your needs (-:.
David Richardson ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Md Lazreg Sent: Wednesday, November 05, 2008 03:50 To: openssl-users@openssl.org Subject: Re: client crash or network issue? 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]
