"Ghost" connections with TCP with winsock - how do they happen?

[VaxoP]

The whole reason for pings is to see if a computer (which youre connected to) is still responding. But I thought that the TCP protocol guarantees delivery or an error is thrown?

What causes these ghost connections - where the winsock state will show connected.. but its not really connected?

[Hack]

By not really connected do you mean you can't ping it?

[CVMichael]

The whole reason for pings is to see if a computer (which youre connected to) is still responding.

That's not true... Ping is used to see if the computer is responsive, and to see how long it takes for data to go there and come back (response-time).

Ping is on port 7 (I think), but when you connect to a computer, the port number is over 1024 (unless it's http (port 80) or ftp (port 12)).
So there is a posibility that you are not able to connect, but still able to ping (or the other way around), because of router/firewall settings...

If you want to keep-alive your connection, then you have to send "ping" data on your already made connection, and not on the ping port...

TCP is not really connected at any time... it is simmilar to UDP, except it has built in functions that in case data was not sent successfully (incomplete or whatever reason), it will re-send again... and after a time-out or after N tries it will error the sender to let you know the data was not sent, and "disconnect"...

[VaxoP]

Oh thats interesting I had no idea

So is it possible for winsock to be connected (state 7) and yet be unresponsive (at either the client or server end)? or would an error be thrown?

And the 'keepalive' packet you were talking about - does windows automatically 'close' TCP connections if no data has been sent through them in a while?

[CVMichael]

Oh thats interesting I had no idea

So is it possible for winsock to be connected (state 7) and yet be unresponsive (at either the client or server end)? or would an error be thrown?

I think i read some threads a while back where people using winsock are saying that when they connect through a wireless network, the winsock does not send an event when the connection is broken until you send some data and winsock finds out it cannot send it. I don't know if that is a bug, and it was fixed, or if it's something that is supposed to happen. But in general, winsock should raise an event when the connection is broken, either through "Error" event or "Close" event... but if you want to make sure that you get an event, then you have to send data most of the time (or at least 1 or more bytes every 1 second, to keep the conneciton alive if you need the event as fast as possible). You can write code so that it will ignore data that is supposed to be as "ping". For example you can do Winsock.SendData "PING", and on the receiver, whenever it receives "PING" it either ignores it, or send back another ping, like "PING_OK" as a response, so the sender of the original "PING" knows that the client acknoleged it, and the sender can record the time it took from sending "PING" to receiving "PING_OK". And that time can be used to display to the user, and also the time can be used for such applications that do streamming to know the delay time, and therefore it will have effect on the encoding for the streamming so that the sound(and/or video) won't be interrupted too often. (but now i'm going into things that are off topic)

And the 'keepalive' packet you were talking about - does windows automatically 'close' TCP connections if no data has been sent through them in a while?

No, winsock should not close the connection if you don't send any data, but internally the winsock should send a ping once in a while (I'm assuming this cuz I don't know how else it would know if the client is still connected)