Develop Reference

C# - Check TCP/IP socket status from client side

I'd like to provide my TCP/IP client class with a CheckConnection function so that I can check if something wrong has happened (my own client disconnected, server disconnected, server stuck up,...).
I have something like that:
bool isConnectionActive = false;
if (Client.Poll(100000, SelectMode.SelectWrite) == true)
isConnectionActive = true;
based on what MSDN says:
SelectWrite: true, if processing a Connect(EndPoint), and the connection has succeeded; -or- true if data can be sent; otherwise, returns false.
The point is that, testing this with simple server application, I am getting always true from CheckConnection, even if server-listener has been closed and even if server-application has been shutdown; that's weird, because I expect in those cases that both no connection is being processed (already connected minutes ago) and no data can be sent.
I have already implemented a similar connection check on server side using a combination of Poll with SelectRead and Available and it seems working properly; so now, should I write something similar also on client side? is the SelectWrite approach correct (but I'm using it improperly)?

There are lots of things you can check but none of them are assured to give you the result you are looking for. Even the implementation you have on the server will not work 100% of the time. I guarantee it will fail one day.
There are FIN packets, which should be sent from the client to the server, and vice versa when a connection is closed, but there is no guarantee that these will be delivered, or even processed.
This is generally known as the TCP Half Open problem.
Closing a TCP Socket is a mutually agreed process, you generally have a messaging protocol which tells the other end that it's closing, or you have some predefined set of instructions and you close after that.
The only reliable way to 100% detect if a remote socket is closed is to send some data to it. Only if you get an error back will you know if the socket has closed.
Some applications which don't send a lot of data implement a keep-alive protocol, they simply send/receive a few bytes every minute, so they know that the remote endpoint is present.
You can technically have two servers that are in a connected state and haven't sent data to each other for 10 years. Each end continues to believe that the other end is there until one try's to send some data and finds out it isn't.

C#: Checking if a socket has a active connection to the server?

I'm trying to find a legitamate wya to tell if the socket has a connection with the server. This becomes invalid if they haven't connected yet, or either the client or server has closed it.
This method is currently returning null before I ever connect to the server using this socket object. Can anyone explain to me why it does that, and how I can fix it?
private static bool IsConnected(Socket socket)
{
return !(socket.Poll(1, SelectMode.SelectRead) && socket.Available == 0);
}

The only way to know if a socket is valid is to send something and get something back. Every other way is a lie. .Available only tells you whether there is data in the current read-buffer. The status is ... at best unreliable. Sockets can die without the OS noticing. Sockets can be artificially spoofed as "alive" by network hardware - in an attempt to prevent temporary network blips (especially for wifi or mobile users) severing all their sockets; but sometimes that device never comes back, and the device in the middle doesn't notice. This means that even TCP-level broken-socket detection is unreliable.
So: send some kind of test message and get something back. That is the only way.

SuperWebSocket what is the meaning of KeepAliveTime

In SuperWebSocket i use the config property IdleSessionTimeOut to delete sessions that are Idle but what is the meaning of KeepAliveTime?

In networking, Keep Alive usually refers to the period of time between "heart beat" messages that the client / server will send to each other to very that the connection is still open and alive. If the message fails to send the sender knows that the receiver has disconnected.
Keepalive at Wikipedia

When P2P Won't Connect, How to "Restart" it in the Client

I have implemented a wcf P2P setup in a simple application.
My question is the result of testing this with multiple clients. Nine times out of ten, all the clients will synch up in the mesh and connect without issue.
However, depending on which client I close and then re-open, it will not reconnect to the mesh. The other clients do not see it.
My question is how can I perhaps close and re-open the p2p on this client so it can attempt to connect again? I'd set a timer perhaps that every minute or so if it isn't connected, it might assume there is an issue so it would close it's p2p endpoint or whatever and then re-open it to refresh the whole thing.
I ask this since if I close this client, then re-open it, it will reconnect to the mesh.
I want fool-proof connections. Such as, you open a client and the client will figure out if it has to restart or it isn't getting connection after a certain amount of time so it attempts to "flush" the connection and rebuild it.
Does this make sense?

It's going to be difficult to determine that you're not connected to the mesh because of some unknown fault condition rather than simply being alone.
The IOnlineStatus property on the peer channel can tell you if you're alone in the mesh (false), or if you have connected peers (true). You can get this property by registering for the status change event like so:
IOnlineStatus status = myPeerChannel.GetProperty<IOnlineStatus>();
status.Online += new EventHandler(MyOnlineEventHandler);
status.Offline += new EventHandler(MyOfflineEventHandler);
So I suppose one way to do this would be to have a timer that checks your online status and if you go more than X amount of time being offline, dispose of your channel and create a new one.

C# Client-Server application problem

I run my application on a network and in some cases the client lost connection to the server. After this time, when I wanted to send a message to the server I receive the following error: Operation not allowed on non-connected sockets (something like this).
I thought to create an event for object type TcpClient and when tcp_obj.Connected = false to call a function to discontinue execution of the current code. How could I do this?
Or giving me other suggestios.
Thanks.

I know at least from socket programming in Java that when a client loses connection to the server, the server does not and can not know about it. You need a heartbeat of some sort to detect the early disconnection.
We often use a heartbeat in our client/server applications to detect early disconnections and log them on the server. This way the server can close the associated socket and release the connection back to the pool.
Simply send a command to the client periodically and wait for a response. If no response is garnered within a timeout assume disconnect and close streams.

I would simply first check your connection object to ensure you are connected, prior to attempting to send the message. Also make sure that you are putting your send-logic inside of a try-catch, so that if you do happen to get disconnected mid transmission, you'll be able to resume without blowing your application apart.
Psuedo-Code:
private void SendMessage(string message, Socket socket)
{
if(socket.connectionState = States.Connected)
{
try{
// Attempt to Send
}
catch(SocketException Ex)
{
// Disconenct, Additional Cleanup Etc.
}
}
}
If you are in C#, prior to your connection state changing, you will have a socket disconnected event fire, prior to your connection state changing. Make sure you tie this event up as soon as your socket connects.

Can we know why you use TCP sockets? Is for calling a tcp device o server code?
I recommend you if is for calling a .net server app use Windows Communication Foudation. It is simple to expose services by net.tcp, http, etc.
Regards,

Actually this is a very old problem,
If I understand your question correctly you need a way to know whether you're application is still connected to the server or vice versa.
If so then a workaround is to have a UDP connection just to check the connectivity (overhead I know, but its much better then polling on Connected state), you could check just before you send you're data.
Since UDP is not Connection oriented you don't need to be connected when you send the data