How to detect client disconnection from server using tcpclient

Question

0.00/5 (No votes)

See more:

I have two separate applications Client and Server used to send and receive data from Ethernet Cable. The Client application sends the data to server. First when the server application is started, it starts accepting client request to accept data. As soon as client is connected , Server thread is started to receive data from Client. Whenever Client application is stopped, there must be either some command send to the server to notify that it has disconnected or there must be some way to detect client disconnection at server end so that thread can be closed for receiving data from Client. I am using TCPClient for this purpose. Kindly suggest some way to do this.
Thanks

What I have tried:

i am trying to disconnect a client from a server but the server still sees it as being connected.

Posted 7-Jun-18 19:39pm

Wahaj Khan

Updated 8-Jun-18 8:02am

Add a Solution

Comments

Rob Philpott 8-Jun-18 6:18am

OK, this is not an authorative answer as I'm not absolutely sure, but I think that if you have a TcpClient server-side, and presumably you have got a stream from it from which you are reading what the client sends you.

Reading from the stream synchronously will block, until bytes are received. In the event of a disconnect the call will unblock, but you will have read no bytes.

I *think* you can use this after which you should do the close/shutdown cycle.

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Jochen Arndt · Answer 1 · 2018-06-07T23:12:00

Each side of a connection should inform the other side when it closes the connection.

This must be done at data protocol level. For example one side sends a request to stop communication and the other answers with an acknowledge response. The side sending the request closes the connection when the response has been received and the other side after the response has been send.

To handle unexpected disconnections use the function provided in solution 1 by Richard. But note that that is returning the state of the most recent operation which is usually not the actual state. To trigger getting the actual state just send a request to the other side. This might be a special request that must not be answered (kinf of NOOP / No Operation or keep alive). If the other side is no longer present, sending the request will fail and the connection (and the thread) can be closed.

Gerry Schmitz · Answer 2 · 2018-06-08T08:03:00

Solution 3

The "server" "drops" the connection after a period of time if no activity ("times out").

The "server" cannot depend on a client to close "its" connection, because the client(s) could "die" at any given time before having sent any "last requests".

Posted 8-Jun-18 8:03am

Gerry Schmitz

Richard MacCutchan · Answer 3 · 2018-06-07T21:55:00

Solution 1

See TcpClient.Connected Property (System.Net.Sockets)[^]

Posted 7-Jun-18 21:55pm

Richard MacCutchan