System.Net.Sockets.TcpClient and System.Net.Sockets.TcpListener. H

System.Net.Sockets.TcpClient and System.Net.Sockets.TcpListener. H

Post by UmFodWwgQW » Wed, 03 Aug 2005 20:45:21



Hi Claire,

I also checked the DataAvailable is always successful even after the socket
has been
closed by remote server.
As per MSDN it should throw an exception of type IOException or
SocketException:
_ If the remote host shuts down or closes the connection, DataAvailable
throws a SocketException_

I have experienced similar problems when i was coding for Socket, have a
look at the following thread named [.NET Socket]:

http://www.yqcomputer.com/ %22.NET+Socket%22&dg=microsoft.public.dotnet.languages.csharp&cat=en-us-msdn-visualtools-vcsharp&lang=en&cr=US&pt=ed4263a6-cf84-4d66-b0fb-befccc28a9bd&catlist=6A7CD498-017F-42B4-997F-87D976E887DE%2C774F24A2-F71F-425F-AC2B-DC48AB0DA5C9&dglist=&ptlist=&exp=&sloc=en-us
 
 
 

1. System.Net.Sockets.TcpClient.Close() doesn't close the socket!

2. "closeOnExec" semantics in .NET with System.Net.TcpListener and System.Diagnostics.Process.Start()

So I'll preface this with the fact that I'm a UNIX developer by training and
have just recently gotten in to C# development on Windows. I'm basically
running in to a problem whereby I suspect something to do with process
groups or threads and closeOnExec semantics (to speak in POSIX terms) is
causing me a problem. I've got a windows service (let's call it
"myService") that, among other things, does :
onStart
creates a TcpListener on a port and starts it

onStop
calls stop on the TcpListener

In addition, while it's running, I can cause the service to "spawn" another
program that invokes "net stop myService" and then "net start myService".
After that, the new instance of myService doesn't seem to be listening on
the port. If I call "net stop myService" and "net start myService" from a
separate shell, everything works fine.

This makes me think that something about the fact that I'm spawning the
killer from within the service keeps some remnants of the TcpListener
around, which keeps the next instance of it from being able to bind to that
port. In POSIX terms, it's like I didn't have closeOnExec set on my socket
so the child inherited it. But I don't really understand the semantics of
process forking and network connections in the .NET and Windows world.

I use System.Diagnostics.Process.Start() to spawn my child process (and just
never call WaitForExit() so it works like a fork/exec). Should I be using a
different mechanism to create this new process such that it doesn't inherit
the TcpListener? Should I be marking my TcpListener in some way so that it
gets closeOnExec semantics? Or is there a better newsgroup to ask this
question in (admittedly, this is more a .NET question than a C# question,
but it's C# code)

Thanks,
Doug

3. System.Net.Sockets.TcpClient <---> Indy

4. System.Net.Sockets.Socket closing prematurly

5. System.Net.Sockets.Socket (Get state of Message)

6. System.Net.Sockets.Socket threw an exception

7. System.Net.Sockets.Socket Bug?

8. Inheriting from System.Net.Sockets.Socket problems.

9. Issue with multiple threads and System.Net.Sockets.Socket

10. Serious Socket Programming Problems With System.Net.Sockets.NetworkStream

11. Overriding System.Net.Sockets.Socket class

12. Problems sending data with System.Net.Sockets.Socket

13. Overriding the constructor for System.Net.Sockets.Socket

14. System.Net.Sockets.Socket Memory Leak

15. System.Net.Socket.Socket