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]

Re: TCP IP Programming

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

HTH
Alex

"MR" <biconix@att.ne t> wrote in message
news:Oj4FkjiqDH A.976@tk2msftng p13.phx.gbl...[color=blue]
> i would appreciate some assistance in finding a reference that describes[/color]
how[color=blue]
> to set up a tcp/ip server/listener in c#. also samples would come in[/color]
handy.[color=blue]
> thanks
> m
>
>[/color]

[Doug Wyatt]

Re: TCP IP Programming

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


"AlexS" <salexru2000NO@ SPAMsympaticoPL EASE.ca> wrote in message
news:OuVHz5iqDH A.2000@TK2MSFTN GP09.phx.gbl...[color=blue]
> Check TcpListener class in Framework SDK help (or on msdn site).[/color]
Description[color=blue]
> of class provides simple samples for listening and accepting connections.
>
> HTH
> Alex
>
> "MR" <biconix@att.ne t> wrote in message
> news:Oj4FkjiqDH A.976@tk2msftng p13.phx.gbl...[color=green]
> > i would appreciate some assistance in finding a reference that describes[/color]
> how[color=green]
> > to set up a tcp/ip server/listener in c#. also samples would come in[/color]
> handy.[color=green]
> > thanks
> > m
> >
> >[/color]
>
>[/color]

[Jon Davis]

Re: TCP IP Programming


"Doug Wyatt" <newsreader7@st arbak.net> wrote in message
news:uTv4vHlqDH A.2416@TK2MSFTN GP10.phx.gbl...[color=blue]
> 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.[/color]

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.
[color=blue]
> 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[/color]
the[color=blue]
> port (as though the killing-program inherited it from the first instance[/color]
of[color=blue]
> the service and thus windows doesn't think it's been let go)?[/color]

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.

// StopPriorProces s(); // todo: here, stop the old process
bool error = true;
while (error) {
try {
TcpListener myTcpListener; // ...
// myTcpListener.L isten(); // todo: bind to port
error = false;
} catch {
error = true;
Thread.Sleep(0) ;
System.Windows. Forms.Applicati on.DoEvents();
}
}

HIR [Hope I'm Right],
Jon

[color=blue]
> If I run the
> killing-program by hand from a command shell (so it wouldn't have[/color]
inherited[color=blue]
> the listen from the service) I don't have this problem.
>
> Thanks,
> Doug
>
>
> "AlexS" <salexru2000NO@ SPAMsympaticoPL EASE.ca> wrote in message
> news:OuVHz5iqDH A.2000@TK2MSFTN GP09.phx.gbl...[color=green]
> > Check TcpListener class in Framework SDK help (or on msdn site).[/color]
> Description[color=green]
> > of class provides simple samples for listening and accepting[/color][/color]
connections.[color=blue][color=green]
> >
> > HTH
> > Alex
> >
> > "MR" <biconix@att.ne t> wrote in message
> > news:Oj4FkjiqDH A.976@tk2msftng p13.phx.gbl...[color=darkred]
> > > i would appreciate some assistance in finding a reference that[/color][/color][/color]
describes[color=blue][color=green]
> > how[color=darkred]
> > > to set up a tcp/ip server/listener in c#. also samples would come in[/color]
> > handy.[color=darkred]
> > > thanks
> > > m
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[AA]

Re: TCP IP Programming

Check

https://www.devshock.com

"MR" <biconix@att.ne t> escribió en el mensaje
news:Oj4FkjiqDH A.976@tk2msftng p13.phx.gbl...[color=blue]
> i would appreciate some assistance in finding a reference that describes[/color]
how[color=blue]
> to set up a tcp/ip server/listener in c#. also samples would come in[/color]
handy.[color=blue]
> thanks
> m
>
>[/color]

[Doug Wyatt]

Re: TCP IP Programming


"Jon Davis" <jon@REMOVE.ME. PLEASE.jondavis .net> wrote in message
news:eimXNplqDH A.488@tk2msftng p13.phx.gbl...[color=blue]
>
> [...]
>
> Windows does not have "child processes", each process is independent.[/color]
There[color=blue]
> is no direct correlation, to my knowledge, of interacting two processes[/color]
that[color=blue]
> both utilize TCP/IP, except using Windows API calls or else opening a[/color]
TCP/IP[color=blue]
> socket on another application port and communicating "over the wire". You
> can, of course, indirectly query the stack to see if another application[/color]
is[color=blue]
> bound to a specific port, such as by attempting to bind to the port and
> handling any exceptions that occur in that attempt.
>[/color]

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.
[color=blue]
> [...]
>
> 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.[/color]

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

[color=blue]
> [...]
>
> HIR [Hope I'm Right],
> Jon
>
> [...][/color]

[Jon Davis]

Re: TCP IP Programming


"Doug Wyatt" <newsreader7@st arbak.net> wrote in message
news:enS78dsqDH A.2536@tk2msftn gp13.phx.gbl...[color=blue]
>
> "Jon Davis" <jon@REMOVE.ME. PLEASE.jondavis .net> wrote in message
> news:eimXNplqDH A.488@tk2msftng p13.phx.gbl...[color=green]
> >
> > [...]
> >
> > Windows does not have "child processes", each process is independent.[/color]
> There[color=green]
> > is no direct correlation, to my knowledge, of interacting two processes[/color]
> that[color=green]
> > both utilize TCP/IP, except using Windows API calls or else opening a[/color]
> TCP/IP[color=green]
> > socket on another application port and communicating "over the wire".[/color][/color]
You[color=blue][color=green]
> > can, of course, indirectly query the stack to see if another application[/color]
> is[color=green]
> > bound to a specific port, such as by attempting to bind to the port and
> > handling any exceptions that occur in that attempt.
> >[/color]
>
> 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.[/color]

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

[color=blue]
> But I have to admit, given .NET semantics, I couldn't
> figure out how it'd be done.
>[color=green]
> > [...]
> >
> > You should never kill a TCP/IP port-bound application's process[/color][/color]
abruptly.[color=blue][color=green]
> > Request a closure. If it is a Windows Service, handle the Stop event [or
> > equivalent]. Then, while closing or stopping, the process should stop[/color][/color]
the[color=blue][color=green]
> > TcpListener.[/color]
>
> I do do that.[/color]

Yep you do.
[color=blue]
> 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[/color]
myService[color=blue]
> ------------ ---------- --------[/color]
--[color=blue]
> ---
> Gets Start Event
> Creates TcpListener
> Gets "restart" msg
> Spawns KillerProg
> Invokes "net stop
> myService"[/color]


Somewhere in there you need to run TcpListener.Sto p() 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