Problem with socket.recieve() , when the clent disconnect
-
in my application once a client connected i run the following code
byte\[\] buffer = new byte\[512\]; while (soc.Connected) { try { soc.Receive(buffer); string encodedstr = Encoding.UTF8.GetString(buffer); this.Invoke(update, new object\[\] { encodedstr }); buffer.Initialize(); } catch (Exception) { if ((soc != null) && (soc.Connected)) { soc.Disconnect(false); } } }but when the client disconnected by closing or accidentally the server runs infinite loop with the last content sent by the client. so my textbox infinitely append the last data to it's content. so i want to know if ther is any other better way of receiving data from client continuously to solve this problem.
-
in my application once a client connected i run the following code
byte\[\] buffer = new byte\[512\]; while (soc.Connected) { try { soc.Receive(buffer); string encodedstr = Encoding.UTF8.GetString(buffer); this.Invoke(update, new object\[\] { encodedstr }); buffer.Initialize(); } catch (Exception) { if ((soc != null) && (soc.Connected)) { soc.Disconnect(false); } } }but when the client disconnected by closing or accidentally the server runs infinite loop with the last content sent by the client. so my textbox infinitely append the last data to it's content. so i want to know if ther is any other better way of receiving data from client continuously to solve this problem.
That is how TCP/IP works. The only sure way to validate if someone is on the other end is by sending something, sometimes quite a bit of something. The way servers commonly solve the problem is that they require clients to send them data during a given time period. If the client fails to send anything then the server disconnects. Another way is to explicitly send a do nothing message to which the other end must respond within a given time period. If they don't respond then disconnect (obviously disconnect as well if there is a delivery failure.)
-
That is how TCP/IP works. The only sure way to validate if someone is on the other end is by sending something, sometimes quite a bit of something. The way servers commonly solve the problem is that they require clients to send them data during a given time period. If the client fails to send anything then the server disconnects. Another way is to explicitly send a do nothing message to which the other end must respond within a given time period. If they don't respond then disconnect (obviously disconnect as well if there is a delivery failure.)
None of the information in your post is correct as far as using a socket class is concerned and applies only to writing your own TCP/IP stack.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
None of the information in your post is correct as far as using a socket class is concerned and applies only to writing your own TCP/IP stack.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
Ennis Ray Lynch, Jr. wrote:
None of the information in your post is correct as far as using a socket class is concerned and applies only to writing your own TCP/IP stack.
What I am referring to is very relevant to anyone using sockets who actually wants to deal with error scenarios. From "Internet Core Protocols" by Hall in Chapter 7 ... "For example, if a PC running a telnet client were powered off, the client would not close the virtual circuit gracefully. Unfortunately, when that happened the TELNET server would never know that the other end had disappeared." The following are just a few of the many, many questions on the internet about "detecting" when the other end of a socket is no longer listening. http://stackoverflow.com/questions/1403097/socket-dis-connects-on-one-end-firewall[^] http://stackoverflow.com/questions/722240/instantly-detect-client-disconnection-from-server-socket[^] http://bytes.com/topic/net/answers/103076-detecting-disconnected-socket[^] http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/c735a352-bf95-4f5c-a672-c790a386f7f5/[^]
-
in my application once a client connected i run the following code
byte\[\] buffer = new byte\[512\]; while (soc.Connected) { try { soc.Receive(buffer); string encodedstr = Encoding.UTF8.GetString(buffer); this.Invoke(update, new object\[\] { encodedstr }); buffer.Initialize(); } catch (Exception) { if ((soc != null) && (soc.Connected)) { soc.Disconnect(false); } } }but when the client disconnected by closing or accidentally the server runs infinite loop with the last content sent by the client. so my textbox infinitely append the last data to it's content. so i want to know if ther is any other better way of receiving data from client continuously to solve this problem.
prasadbuddhika wrote:
while (soc.Connected)
I doubt that is going to serve the purpose that you think it is. That doesn't validate the connection. All it tells you is that at some time in the past that it worked. The following are probably the general run time conditions that one faces with sockets. 1. It fails to connect at all. Reasons: Wrong address, port, firewall rules or the server is down. 2. It runs 3. The server disconnects gracefully. Receive() will return zero. 4. The server takes too long. Reason: Server is locked up. 5. The server never responds. Reasons: Someone kicked out the power plug or the firewall dropped the connection. Notice that in 4/5 no exception occurs. You can get an exception to occur by setting a time out value. That tells you that it hasn't sent data but not why.
-
Ennis Ray Lynch, Jr. wrote:
None of the information in your post is correct as far as using a socket class is concerned and applies only to writing your own TCP/IP stack.
What I am referring to is very relevant to anyone using sockets who actually wants to deal with error scenarios. From "Internet Core Protocols" by Hall in Chapter 7 ... "For example, if a PC running a telnet client were powered off, the client would not close the virtual circuit gracefully. Unfortunately, when that happened the TELNET server would never know that the other end had disappeared." The following are just a few of the many, many questions on the internet about "detecting" when the other end of a socket is no longer listening. http://stackoverflow.com/questions/1403097/socket-dis-connects-on-one-end-firewall[^] http://stackoverflow.com/questions/722240/instantly-detect-client-disconnection-from-server-socket[^] http://bytes.com/topic/net/answers/103076-detecting-disconnected-socket[^] http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/c735a352-bf95-4f5c-a672-c790a386f7f5/[^]
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
Ennis Ray Lynch, Jr. wrote:
See Page 45[^]
I suggest that you make it more explicit how you think I am wrong. Or perhaps you could provide a code sample of a listening socket that will detect that the other end is gone when the power plug is pulled on it.
-
Ennis Ray Lynch, Jr. wrote:
See Page 45[^]
I suggest that you make it more explicit how you think I am wrong. Or perhaps you could provide a code sample of a listening socket that will detect that the other end is gone when the power plug is pulled on it.
I suggest you read the documentation for Windows Sockets and the RFC and use them as guides instead of Google searches yielding results that are questions and answers from non-definitive sources. When you post an answer as an Authority you have some responsibility for accuracy. Using TCP/IP and then manually sending keep alive messages is a waste of the protocol.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
I suggest you read the documentation for Windows Sockets and the RFC and use them as guides instead of Google searches yielding results that are questions and answers from non-definitive sources. When you post an answer as an Authority you have some responsibility for accuracy. Using TCP/IP and then manually sending keep alive messages is a waste of the protocol.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
Ennis Ray Lynch, Jr. wrote:
I suggest you read the documentation for Windows Sockets and the RFC and use them as guides instead of Google searches yielding results that are questions and answers from non-definitive sources. When you post an answer as an Authority you have some responsibility for accuracy.
You are incorrect in the intent of my posting. I know how sockets work having worked with them in C#, Java and C++. I was citing references to back up what I was saying rather than just restating what I said already - which is what you are doing. Feel free to provide some specific references to make your point. Or cite something specific from the RFC. I have in fact read the RFC and the C# documentation. Again...please provide a specific comment on exactly how you think all or part of my response was incorrect.
Ennis Ray Lynch, Jr. wrote:
Using TCP/IP and then manually sending keep alive messages is a waste of the protocol.
This statement indicates that you do not know how TCP/IP works. Again feel free to provide code and a specific scenario that allows a listener to detect when the other end is terminated by a pulled plug. Feel free to provide the code in C#, C++, Java or even Perl. Although I suppose it is possible that you did not understand why I was suggesting a keep alive. Perhaps that is where your confusion lies.