Check if TCP/IP partner disconnected...
-
Hello everybody! I want to have a permanent data transfer to another machine via TCP/IP Socket Communication. I actually coded a solution which will work fine. But one thing does not work: In my code the SocketServer does not recognize that the client has disconnected. How can I recognize this? In the case that the client disconnected, my code is waiting for Data and there is logically no dataflow anymore. Here´s the important extract from my code: [STAThread] public static void Main() { Socket mySocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); IPEndPoint myEndPoint = new IPEndPoint(IPAddress.Any, 65000); mySocket.Bind(myEndPoint); try { mySocket.Listen(20); Socket sa = mySocket.Accept(); byte[] buffer = new byte[5]; string tmpString = ""; NetworkStream myStream = new NetworkStream(sa, true); while (sa != null) { if (myStream.DataAvailable) { int read = 0; read = myStream.Read(buffer, 0, buffer.Length); tmpString = Encoding.ASCII.GetString(buffer, 0, read); Console.WriteLine(tmpString); } } } catch (SocketException sockErr) { Console.WriteLine("Socket Exception: ", sockErr.Message); } catch (Exception err) { Console.WriteLine("Exception: ", err.Message); } mySocket.Close(); } Thanks for any help Norman-Timo
-
Hello everybody! I want to have a permanent data transfer to another machine via TCP/IP Socket Communication. I actually coded a solution which will work fine. But one thing does not work: In my code the SocketServer does not recognize that the client has disconnected. How can I recognize this? In the case that the client disconnected, my code is waiting for Data and there is logically no dataflow anymore. Here´s the important extract from my code: [STAThread] public static void Main() { Socket mySocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); IPEndPoint myEndPoint = new IPEndPoint(IPAddress.Any, 65000); mySocket.Bind(myEndPoint); try { mySocket.Listen(20); Socket sa = mySocket.Accept(); byte[] buffer = new byte[5]; string tmpString = ""; NetworkStream myStream = new NetworkStream(sa, true); while (sa != null) { if (myStream.DataAvailable) { int read = 0; read = myStream.Read(buffer, 0, buffer.Length); tmpString = Encoding.ASCII.GetString(buffer, 0, read); Console.WriteLine(tmpString); } } } catch (SocketException sockErr) { Console.WriteLine("Socket Exception: ", sockErr.Message); } catch (Exception err) { Console.WriteLine("Exception: ", err.Message); } mySocket.Close(); } Thanks for any help Norman-Timo
Norman-Timo wrote: In the case that the client disconnected, my code is waiting for Data and there is logically no dataflow anymore. Ideally this is what a server should do! Other options: - poll the client by sending an "empty" packet, a socket exception will occur if the connection is dead. - ask the client to send some info that it has disconnected, before disconnecting. top secret xacc-ide 0.0.1
-
Norman-Timo wrote: In the case that the client disconnected, my code is waiting for Data and there is logically no dataflow anymore. Ideally this is what a server should do! Other options: - poll the client by sending an "empty" packet, a socket exception will occur if the connection is dead. - ask the client to send some info that it has disconnected, before disconnecting. top secret xacc-ide 0.0.1
Yes the server should do so ;-) But I tested this scenario: I made a connection to the server. Then I send some data and disconnected from server. The server was waiting then. I tried to make another connection from same client, which worked. But the sended data did´nt reached the server anymore, while he is waiting and waiting... I think I have to recognize that the connection was disconnected, so that the socket could set to Listen-Mode again and catches the connection witch an Accept() Method. But while the server is waiting no data transfer is possible anymore. Yeah polling is maybe a solution, but there should be a property to check if TCP/IP-Partner is available (such like that one on client side with: 'mySocket.Connected' or so...) So please help me more Norman-Timo
-
Yes the server should do so ;-) But I tested this scenario: I made a connection to the server. Then I send some data and disconnected from server. The server was waiting then. I tried to make another connection from same client, which worked. But the sended data did´nt reached the server anymore, while he is waiting and waiting... I think I have to recognize that the connection was disconnected, so that the socket could set to Listen-Mode again and catches the connection witch an Accept() Method. But while the server is waiting no data transfer is possible anymore. Yeah polling is maybe a solution, but there should be a property to check if TCP/IP-Partner is available (such like that one on client side with: 'mySocket.Connected' or so...) So please help me more Norman-Timo
Hehe. There IS a "Socket.Connected" property for Sockets. I suspect that you are actually WAITING on that socket. Do not do that. As far as I understand your problem, you have ONE Socket. That is, to say the least, not what anyone expects of a server. Try understanding the concept of either synchronous sockets OR asynchronous sockets. If you choose the latter, you wont have to do any "manual multi-threading". My last project at work was also a server waiting on TCP connections. There is no "worst-case-handling" in there yet, but even if (due to network error or other problems) I lost a few clients, it would not block the whole thing down. I am using asynchronous sockets, which means at runtime the necessary threads are auto-magically created in a threadpool. The whole thing is based on the MSDN "non-blockingserverexample". What you can do to check if your client still is connected: check socket.connection and socket == null (with proper capitalization, of course) or try sending something to your client. You will get an exception if your client is not connected. I do have one advantage: Once a client has connected, he will stream his requests one at a time (receive, process, answer - thats what I do) and each request has a length field in the leading five bytes. So, if a Client has connected, I will immediately receive 13 byte from him, process his request, send my response, then receive the next 13. I KNOW that a client who did not send me the proper shutdown package and has not responded for, lets say, thirty seconds, must be dead. So I can run over my (yet to be implemented) hashtable every thirty seconds and check for timeouts. That way, it will take less than sixty seconds for any dead sockets to be removed.
-
Hehe. There IS a "Socket.Connected" property for Sockets. I suspect that you are actually WAITING on that socket. Do not do that. As far as I understand your problem, you have ONE Socket. That is, to say the least, not what anyone expects of a server. Try understanding the concept of either synchronous sockets OR asynchronous sockets. If you choose the latter, you wont have to do any "manual multi-threading". My last project at work was also a server waiting on TCP connections. There is no "worst-case-handling" in there yet, but even if (due to network error or other problems) I lost a few clients, it would not block the whole thing down. I am using asynchronous sockets, which means at runtime the necessary threads are auto-magically created in a threadpool. The whole thing is based on the MSDN "non-blockingserverexample". What you can do to check if your client still is connected: check socket.connection and socket == null (with proper capitalization, of course) or try sending something to your client. You will get an exception if your client is not connected. I do have one advantage: Once a client has connected, he will stream his requests one at a time (receive, process, answer - thats what I do) and each request has a length field in the leading five bytes. So, if a Client has connected, I will immediately receive 13 byte from him, process his request, send my response, then receive the next 13. I KNOW that a client who did not send me the proper shutdown package and has not responded for, lets say, thirty seconds, must be dead. So I can run over my (yet to be implemented) hashtable every thirty seconds and check for timeouts. That way, it will take less than sixty seconds for any dead sockets to be removed.
Hey thanx! But in my case (I forgot to write this!) I only want to communicate with a static partner. And in my case the communication should never be disconnected, and there is only one case if connection fails: socket error. Only if I start my application I bind the socket to my IPEndpoint and set the Socket to Listen and wait for this client response. After client is responsing the connection is hold and should never end. But there are many reasons why the connection breaks: perhaps the cable was disconnected, or the comm. partner has to reboot..... But nothing helps, so I understand, I have to test the communication and send a "null" package after every certain timespan. Ok thanx to all Your Norman-Timo