You can find some useful ideas in my past answers:
http://www.codeproject.com/Answers/536542/anplusamateurplusquestionplusinplussocketplusprogr#answer2[
^],
http://www.codeproject.com/Answers/165297/Multple-clients-from-same-port-Number#answer1[
^],
specifically on the problem of disconnection:
http://www.codeproject.com/Answers/848979/How-Do-I-Get-To-Know-If-A-A-Tcp-Connection-Is-Over#answer1[
^].
As you can see, one key idea is to have two threads on the service side, one for listening for new connection, another to network stream I/O itself. It solves all the problems. Pay special attention for my recommendation on thready synchronization.
I can see many concerns in the way you approach things. The whole idea to make some
field accessible (non-private) is usually considered as abuse. This is not always so, but the adequate accessible member is a
property, because it can help to encapsulate some processing, such as encapsulation. But it won't solve your problem, too. The key problem is the general use of threads. It is also related to your comment on
Thread.Abort
.
Many say that
Thread.Abort
is unsafe and should not be used. Usually, such advice comes from lack of understanding of what it does; such people associate it with really unacceptable
TerminateThread
. These things are very different. But the truth is: you only should use
Abort
if you understand what it really understand what you do, and not many understand it. I tried to explain things here:
Problem with creating Process from dedicated thread[
^],
Close correcly the thread inside a dll[
^].
Despite the difficulties related to understanding of thread abortion, I can suggest one way to use it really safely. It can be really safely done at the very end of your application runtime. The idea is: you create all the threads you need in the very beginning of your runtime and reuse them all the time. Roughly speaking, at the very end, you can abort a thread even if it is in some unknown state, and, at the very end, you have nothing to lose, at least for some class of applications, such as yours. My past answers should give you the idea:
Making Code Thread Safe[
^],
Running exactly one job/thread/process in webservice that will never get terminated (asp.net)[
^],
pause running thread[
^],
ManualResetEvent and AutoResetEvent in Thread[
^].
(I'm not trying to say that you need to use thread throttling in your application, that is, event wait handles; it is rather related to more general case. As to your application, my point is to avoid creation of threads but reusing the same fixed number of threads. Here is the thing: one common thread design mistake, nearly fatal one, is the attempt to create additional thread per socket; right design is using fixed number of threads, at most, one main thread plus two communication threads on the service side, and reuse the for all sockets.)
This concept couples well with the design of the
thread wrapper I put forward on my other answers:
How to pass ref parameter to the thread[
^],
Change parameters of thread (producer) after it is started[
^] (encapsulation of thread synchronization is explained here),
MultiThreading in C#[
^],
Classes in list updating in their own thread[
^].
I would also add that an adequate form for the service part would be
Windows Service:
Introduction to Windows Service Applications[
^],
Walkthrough: Creating a Windows Service Application in the Component Designer[
^].
It looks like you are trying to develop your application at the level of sockets, using
TcpClient
and
TcpListener
classes. It can be quite an adequate approach. I only want to remind you that it can be done on different levels, from sockets to "classical" remoting or WCF (in your case, most likely,
self-hosted). Please see:
Communication b/w two Windows applications on LAN.[
^],
how i can send byte[] to other pc[
^].
—SA