Detecting socket closed

[redcameron]

This may be a super simple question, but for the life of me I can't find any sources to answer it on Google or I've read something that confused me.

I'm communicating with a server that requires I send it a handle name for my connection, depending on some rules on handle formatting it either accepts/rejects me. The thing is that it rejects me WITHOUT notifying that it's ending the connection.

My question is...is there any way I can detect that the socket has closed? I read a forum that said I can use descr() to feed in the file discriptor but other sources are saying that there is effectively no way of knowing if the socket is still open or not - which doesn't make sense to me (seems like that can't possibly be true).

Thanks in advance.

[neandrake]

I read a forum that said I can use descr() to feed in the file discriptor but other sources are saying that there is effectively no way of knowing if the socket is still open or not - which doesn't make sense to me (seems like that can't possibly be true).

Don't think of a connection as a tie between client and server (that if a connection is cut, both parties would know). A connection is an agreement between client and server that they will communicate. They initiate by sending specialized packets, and then either party can send data to the other. The connection is considered closed if one party sends a specialized packet to indicate that party will no longer participate in that connection.

If you want to check if a connection is closed, you could try sending more data, and error on timeout. I believe that is a most common way, if the server never sends the close-connection (or is never received). Most socket API should provide a way to implement this. What system/platform, etc. are you working on?

[redcameron]

Hi there,

Thanks for that lucid explanation :-) I'm writing for Unix based systems in standard C.

Without repeating myself, here's another thread I created yesterday for another issue I had and managed to resolved quickly: Multiplexing read socket and stdin

More than half way through I end up posting a simplified version of my program, so you can look at that directly.

Basically you're saying that I can apply error checking on my write statement, if a certain value is returned I can assume the socket is closed then end my connection.

Correct?

Thanks!!!

[brewbuck]

Basically you're saying that I can apply error checking on my write statement, if a certain value is returned I can assume the socket is closed then end my connection.

Correct?

Thanks!!!

Well, you can't really assume anything other than you got a timeout. That doesn't necessarily mean the other end closed the connection (at any rate, you should get a RST unless the other end is doing something stupid) -- it just means your packet never got there and/or was never acknowledged. That could be due to anything, like Godzilla eating the Internet for instance

[redcameron]

Heh, evil godzilla.

So basically...I'm probably so dumb that I need this explicitly stated. I can't assume that the server closed the connection but what you're getting at is, I'm safe if I just end the connection of the write doesn't work?

lol...

[neandrake]

It's a fairly safe assumption that the connection was lost during a timeout. You could try to re-establish the connection after a timeout.

[redcameron]

So I'm not clear yet...when you say timeout to mean a literal timeout what I would have set in my select statement? I don't have this set for a specific reason, to force my application to block indefinitely (which IS an intended effect).

What do YOU mean by timeout?

[brewbuck]

So I'm not clear yet...when you say timeout to mean a literal timeout what I would have set in my select statement? I don't have this set for a specific reason, to force my application to block indefinitely (which IS an intended effect).

What do YOU mean by timeout?

TCP itself has a configurable timeout. I think that's what we're talking about.

[slingerland3g]

Why don't you just have your server send some response back upon a rejection? As it appears you have already gone through the TCP three way handshake or else how would the server not read your handle you are sending. Are you sure that is even occuring?

At what point in the TCP session are you breaking? For instance...

Overview of a TCP communications session

You may already know if this gem!

Overview of a TCP communications session


The question is if your server does not respond at all then you are solely relying on how TCP is to detect a closed session and that mainly will fall back on your defined timeouts as already noted.