> Thank you again David, You are welcome.
> 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! Logical, nothing has happened to the connection yet. > it does not detect that its connection to the client is lost... It's not lost. There could be a backup link. It has no idea. > SSL_read is not even called because my select does not detect > any change on the socket.... This surprised me. What changed? Before, if you had sent a packet, it would have gotten through. Now, if you had sent a packet, it wouldn't have gotten through. But nothing that has actually happened or will happen has changed. There is no reason anything should happen in this case. The network may well recover before even any packets are dropped. It would be crazy to drop a connection in that case. > 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. It's tricky. You would have to actually probe the state of the interface or keep up a "test connection" to a local machine and see if that test connection fails too. I still think your whole mechanism is wrong. Why should it matter to the *server* whether the client program crashed or something else happened? The server has no way to know what the consquences of a crash are for the client. It sounds like you're violating conceptual boundaries. > 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. Why? The client could get plugged back in a second later. Do you want all your connections to break just because a wire vibrated for a split second? TCP is robust. > 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... You are thinking about this all wrong. The connection is still just fine, it just has a potentially momentary delay/interruption. It has not failed yet. You don't want to treat split-second routing disruptions as hard failures, that's craziness. > 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... A momentary connection disruption means nothing. Why should you care? > Is there a way my server can be notified? No, because there is no way to know. The point at which the failure occurs has no way to know that it's a single point of failure. It has no way to know how long the failure will last. And as I said, there really has not been anything that has actually failed yet. > 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... Unless an idiot designed the protocol, follow its specifications to handle this case. If the protocol didn't take this into account, it's seriously broken and should be redesigned. It sounds like you may have painted yourself into a corner. Protocols layered over TCP have to at least be designed by people who are very knowledgeable about TCP properties. I would give serious thought to starting over or implementing a client-side proxy to "fix" the protocol. > 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... So why wasn't the protocol designed with this in mind? > Thanks again for all your help. Good luck. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
