TCP IP Programming

[MR]

i would appreciate some assistance in finding a reference that describes how
to set up a tcp/ip server/listener in c#. also samples would come in handy.
thanks
m

 

[AlexS]

Check TcpListener class in Framework SDK help (or on msdn site). Description
of class provides simple samples for listening and accepting connections.

HTH
Alex

 

[Doug Wyatt]

Are there any good sites (or books) that describe some of the more detailed
nuances of TCP/IP programming with .NET? The MSDN description of the
TcpListener class doesn't really go in to much detail. In particular,
issues such as how these connections are shared between processes? I
understand how this stuff works on linux (closeOnExec flags, referencing
FD's by integer ID in spawned processes, etc.) but in an object oriented
model, where the children processes don't have access to the same object
namespace, I'm not sure how it would work.

For example, I am having a problem where I have a windows service that
spawns another program that stops the first service and then restarts it,
and the second instance of service doesn't seem to be able to listen on the
port (as though the killing-program inherited it from the first instance of
the service and thus windows doesn't think it's been let go)? If I run the
killing-program by hand from a command shell (so it wouldn't have inherited
the listen from the service) I don't have this problem.

Thanks,
Doug

 

[Jon Davis]

In particular,
issues such as how these connections are shared between processes? I
understand how this stuff works on linux (closeOnExec flags, referencing
FD's by integer ID in spawned processes, etc.) but in an object oriented
model, where the children processes don't have access to the same object
namespace, I'm not sure how it would work.

Windows does not have "child processes", each process is independent. There
is no direct correlation, to my knowledge, of interacting two processes that
both utilize TCP/IP, except using Windows API calls or else opening a TCP/IP
socket on another application port and communicating "over the wire". You
can, of course, indirectly query the stack to see if another application is
bound to a specific port, such as by attempting to bind to the port and
handling any exceptions that occur in that attempt.

For example, I am having a problem where I have a windows service that
spawns another program that stops the first service and then restarts it,
and the second instance of service doesn't seem to be able to listen on the
port (as though the killing-program inherited it from the first instance of
the service and thus windows doesn't think it's been let go)?

You should never kill a TCP/IP port-bound application's process abruptly.
Request a closure. If it is a Windows Service, handle the Stop event [or
equivalent]. Then, while closing or stopping, the process should stop the
TcpListener.

Wait also for the binding to be released.

// StopPriorProcess(); // todo: here, stop the old process
bool error = true;
while (error) {
try {
TcpListener myTcpListener; // ...
// myTcpListener.Listen(); // todo: bind to port
error = false;
} catch {
error = true;
Thread.Sleep(0);
System.Windows.Forms.Application.DoEvents();
}
}

HIR [Hope I'm Right],
Jon

 

[AA]

Check

www.devshock.com

 

[Doug Wyatt]

[...]

Windows does not have "child processes", each process is independent. There
is no direct correlation, to my knowledge, of interacting two processes that
both utilize TCP/IP, except using Windows API calls or else opening a TCP/IP
socket on another application port and communicating "over the wire". You
can, of course, indirectly query the stack to see if another application is
bound to a specific port, such as by attempting to bind to the port and
handling any exceptions that occur in that attempt.

Really? I had gathered that Windows didn't have a "process tree"
parent/child relationship like UNIX systems do, but I could swear that I
came across references to windows apps sharing open files and network
connections that way. But I have to admit, given .NET semantics, I couldn't
figure out how it'd be done.

[...]

You should never kill a TCP/IP port-bound application's process abruptly.
Request a closure. If it is a Windows Service, handle the Stop event [or
equivalent]. Then, while closing or stopping, the process should stop the
TcpListener.

I do do that. The chain of events is something like the following. And,
just to be clear, the two services are actually the same service. Just
different instantiations of it.

Old myService KillerProg New myService
------------ ---------- ----------
---
Gets Start Event
Creates TcpListener
Gets "restart" msg
Spawns KillerProg
Invokes "net stop
myService"
Waits for that to
finish
Gets Stop Event
Closes TcpListener
Exits
Sleeps 2 seconds
Invokes "net start
myService"
Waits for that to
finish

Gets Start Event

Creates TcpListener
Exits


and at this point, clients cannot connect to the new TcpListener, though,
oddly, I didn't get a failure from the second TcpListener creation. And,
like I said, if I invoke KillerApp from a cmd.exe shell (as opposed to
having myService invoke it itself), it works just fine. So it would seem
that it has something to do with how the first myService shutsdown when it
has spawned this process.

As an experiment, I added a call to close the TcpListener to myService right
before it invokes KillerApp. This seemed to solve the problem (again, very
similar to what would happen in POSIX had I not set it to closeOnExec).
Unfortunately, I can't leave it this way since I don't know whether
KillerApp is really going to restart the services (it's not really
KillerApp, it's more like "HelperApp", which sometimes turns out to restart
the services). So it really does seem that something about spawning off
the KillerApp before I close the TcpListener keeps it from dying correctly
when stopped by a process that it itself spawned.

Hrm....

Thanks,
Doug

[...]

HIR [Hope I'm Right],
Jon

[...]

 

[Jon Davis]

[...]

Windows does not have "child processes", each process is independent. There
is no direct correlation, to my knowledge, of interacting two processes that
both utilize TCP/IP, except using Windows API calls or else opening a TCP/IP
socket on another application port and communicating "over the wire". You
can, of course, indirectly query the stack to see if another application is
bound to a specific port, such as by attempting to bind to the port and
handling any exceptions that occur in that attempt.

Really? I had gathered that Windows didn't have a "process tree"
parent/child relationship like UNIX systems do, but I could swear that I
came across references to windows apps sharing open files and network
connections that way.

Ah, no. Please share where you saw this. What a neat trick that would be....
Very useful.

On the other hand, Windows does support DCOM and DDE but it's sloppy and
..NET doesn't speak either one very well.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/about_network_dde.asp

But I have to admit, given .NET semantics, I couldn't
figure out how it'd be done.

[...]

You should never kill a TCP/IP port-bound application's process abruptly.
Request a closure. If it is a Windows Service, handle the Stop event [or
equivalent]. Then, while closing or stopping, the process should stop the
TcpListener.

I do do that.

Yep you do.

The chain of events is something like the following. And,
just to be clear, the two services are actually the same service. Just
different instantiations of it.

Old myService KillerProg New myService
------------ ---------- -------- --
---
Gets Start Event
Creates TcpListener
Gets "restart" msg
Spawns KillerProg
Invokes "net stop
myService"

Somewhere in there you need to run TcpListener.Stop() before killing it. Are
you doing that? This suggestion shouldn't be necessary, though;
TcpListener's deconstructor should unbind from the TCP/IP stack
automatically. So I don't know. I have seen other problems in other areas of
the .NET framework where deconstructors seemed to be missing. For instance,
for the system tray icon object (NotifyIcon) you have to make its Visible
property to False before unloading it or else the icon will linger in the
Windows system tray until you mouse over it (at least this is true for me in
Windows XP).

Good luck, hope others are able to help.

Jon