TCP Sockets checking aliveness

TCP Sockets checking aliveness

• Nadeem Hashmi

  Sorry, posted in the wrong forum. Can you move to .NET Framework Networking and Communication please.
  
  

• Dylan K Dreyer

  That's news to me, not like I'm an expert though. I thought I had all this covered, as I tested by shutting down the other machine, ripping out the cable etc.

  If you don't mind, could you please give me a scenerio where you won't either receive 0 bytes or get an exception if the other side shuts down I'd like to test.

  Thanks,

  Mike

  
  

• teapeng

  simply kill either side in the taskmanager
  
  

• Sergei Almazov

  Ok, I guess I'm missing something here. I started up my server, connected with the client, then shut down the server. My client gets a socket exception with the .ErrorCode as 10054.

  I get the same winsock error when I shut down via Task Manager. Shutting down my network connection gives me error 10054 on the server and client.

  Like I said, I'm not an expert, but you seem to get notification when the connection gets interrupted.

  Am I missing something here

  Mike

  
  

• Manikandan158716

  Yes, I was testing both client and server on localhost. I moved the server to another machine on the LAN, tested and same result - I get notified when the server shuts down.

  I don't have the ability to run over the internet as I'd need to place my app somewhere. I don't see why this would be any different though, but who knows. The only production socket stuff I've done runs over a LAN and this app seems to run fine - that is, the server goes down pretty frequently (out of my control) and my app can tell and attempt to reconnect.

  Are you using synchronous or asynchronous methods Reason I'm asking is because I'm using asynchronous methods and these exceptions are all being caught in the callback methods.

  Regards,

  Mike

  
  

• sgarlad

  The point is, closing the application normally, shutting down the pc, will always result in a socket disconnect call and that is why you are getting the notification. However, if you freeze the server for example there will be no notification on the client side. Also, what I already said before: If you open the task manager, go to processes, look for the process name of your server and then hit end process, it will kill the server process without a disconnect call to the socket. This will leave the client unnotified.
  
  Back to my original problem, I think what I'm going to do is: When the client receives data in the receive callback I'll treat it the same way as if a ping was received. On the server side I'll handle a call to the send callback the same as if a ping was sent from the client and the server replied to it
  
  
  

• dumbo

  This is not true. If remote server crashes or connection is interrupted you will not be notified that the connection was closed
  
  

• hanct

  Hm, is your client/server constantly sending something You said server "shut down". Did you really go into task manager->processes->end process I really don't see why you would get notified unless one side tries to send something.
  I'm using async sockets as well
  
  

• Mikeyw

  I'm spanish please use simple words with me.

  I'm just having the same problem whit some variations. I get a SocketExeption whose ErrorCode is 10022 but I don't know the meaning of that error, is there explained

  That error ocurs when I try to do this when de TCPClient is Connected:

  TCPClient.Disconnect(true)

  I have try a lot of methods using Disconnect but the result is always de same and I have to notice when the RemoteTCPClient loses the connection. If I try "If TCPClient.Connected=False..." but since I first Connect even if the RemoteTCPClient ends the local TCPClient.Connected Is True...

  Any better solution (not using that ping method I mean)

  
  

• angel180

  When I said "shut down" I meant I walked over to the other machine and x-ed out of the application. I get the same results if I shut down my network connection (I'm wireless here, so no cable to rip out - previously I've tested by ripping out the cable, with the same result).

  And no, there's no continuous client/server communication.

  I'm not sure what you mean by "You need to do it in process".

  Anyway, whatever I'm doing seems to work for me and like I said, it's in production and behaves as expected. I think we're getting away from your original question. Unless of course you'd like to try some stuff together and see what's going on.

  If it were me, and I needed to send a keep-alive or heartbeat message, but don't want to send if there's other, bigger messages to send, I'd think about implementing some sort of queue mechanism. Place your messages (and ping packets) in a queue, send from that queue. Maybe you'd do something like "if a keep alive message wasn't placed in the queue within the last three seconds, add it to the queue".

  Completely off the top of my head, but I think something like that would work. Of course, I don't know how you're sending your ping packets now.

  Interesting stuff, I wish I knew what we were doing different.

  Mike

  
  

• deepu_verma

  see it this way ... how should either side be able to notify a disconnect
  a) It must receive something that tells it that the other side went down (not possible if someone cuts the wire in half)
  b) It must try to send something and don't reach the end point (However, as TCP only sends something when it has to you don't notice the other side being down unless you try to send something)
  
  

• Nandor

  I think what you've done is you went into the task manager->Applications and ended the process there That doesn't kill the process but does rather more does a graceful shutdown. You need to do it in processes
  
  

• Jetttik

  are you testing on localhost
  Try testing over inet
  
  

• Motley

  Not sure if this works for you, but I've never bothered with pinging as I don't think you need to. Reason is, if the connection breaks, you'll either get an exception or receive data with a length of zero. Either one can be trapped and then you can attempt to reestablish the connection.

  Mike

  
  
• TCP Sockets checking aliveness