How Do I Get To Know If A A Tcp Connection Is Over

Question

0.00/5 (No votes)

See more:

Hi everyone, thank you for trying to help me
I'm making a DVD Farm on the cheap and i'm trying to write the code for myself in VB.Net
i have made a software that runs on every computer and a software for the main computer that sends commands to all of them.

Now, i always want the machines to listen to the main computer for connection, so i wrote this code:
Variables:

VB

Dim server As New TcpListener(45888)
        Dim client As New TcpClient
        Dim stream As NetworkStream

First, i wait for connection:

VB

server.Start()
        client = server.AcceptTcpClient
        stream = client.GetStream

Then, with the use of a thread, i start the listening cicle:

VB

While client.Connected
If client.Available > 0 Then
''read commands
''do stuff
End if
End While

Here's the problem:
When i connect to the machine with this code on it, once i disconnect, the machine still thinks it's connected, making it impossible to connect to it a second time, the "client.Cinnected" doesn't seem to work properly, i would like the machine to detect when the connection is over to restart the process.

Is this supposed to work? am i doing something wrong?

Posted 2-Dec-14 3:35am

xthehacker2000x2

Add a Solution

1 solution

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)

Sergey Alexandrovich Kryukov · Answer 1 · 2014-12-02T04:52:00

I don't understand why would you use client.Connected at all. The problem looks very simple to me; I face such disconnections everywhere and never had problems with it.

The idea is: you should have some main cycle where you exchange data with all clients. Inside that cycle, everything should be done under the try-catch loop. If you, for an experiment, at first step, catch all the exception and some client disconnects, you will see what exceptions are thrown and handle them specifically in your next version of the code. From exception information, you will see what client has been disconnected (a client is represented either as the instance of Socket representing remote socket, or an instance of TcpClient). When you determine that, remove the client from the client collection and continue the loop with other clients, or do whatever is needed. Naturally, something like that should be done on the client side.

Note that there is one special case of disconnection, which is an issue. If you disconnect the application (just terminated it), the situation is detected immediately and the exception is thrown. The issue is when you physically break the network cable, not changing anything. This situation is only detected after a relatively long timeout. (You can define your timeout values, but its reasonable to have fairly long time-outs. The bright side is that you can re-connect the cable, and then the communication will continue.) Basically, such wait is always involved. You can experiment with it on a LAN, for example. The work-around would be checking up physical connection with a separate channel and short timeout values (pinging is one of such option), but this strategy would be redundant/wasteful and hardly makes much sense.

I assume that you work with all clients in the same thread (or even work with only one client). However, main issue here is threading. You really need to have at least two separate communication threads on the server side: one thread accepts the new client, another thread reading/writing from/to the network stream. Of course, you need to use appropriate locking for the shared data (such as the collection of connected client or something else related to the clients, such as client-related data).

Please see also my past answers:
an amateur question in socket programming[^],
Multple clients from same port Number[^].

Note my paragraph about graceful disconnection: I try to explain why it hardly makes sense: the application should be ready for all kind of disconnections anyway.

—SA