Socket bug

[Lloyd Dupont]

I'm doing some stress test for some TcpIP communication.
rougly it's someting like that:

for(i=0; i<1000; i++)
{
Sockect s = new Socket()
s.Connect(endPoint);

NetworkStream ns = new NetworkStream(s);
// .... read / write about 10k random bytes
....
ns.Close();
s.Close();
}

the problem is sometimes (usually at the 994th iteration, but not always) I
have a socket exception on Connect()
(NativeErrorCode: 10048, only one socket could listen at a given
address/port) ???
It's a client socket, and I don't bind it at all !!!

 

[Greg Ewing [MVP]]

Lloyd, could you post a working, simple sample which demonstrates what you
are seeing? A simple command line app would be perfect.

 

[_]

s.Close();

The socket handles don't go away immediately, and so it sounds as if you're
running out.



--
What the caterpillar calls the end,
the rest of the world calls a butterfly.
~ Lao-tzu

Components For Thinkers
www.abderaware.com
zane @at@ abderaware .dot. com

 

[Ron Alberda [MSFT]]

This is a known issue. You are running out of "wildcard" ports. When you do
a connect the socket uses a wildcard port for receiving data. Each
connection goes into a "TIME_WAIT" state to prevent immediate re-use of the
port. This is by design to prevent port hijacking. The port becomes
available again after two minutes. If you do a "netstat -a" when you notice
the socket Exception you'll see lots of connections in the "TIME_WAIT"
state.

The workaround is to do a System.Threading.Thread.Sleep for ~2 minutes when
you get close to 1000 connections.

-Ron

 

[Lloyd Dupont]

ho, ok.
thanks for the info.
I had an excellent work around since then, anyway ;-)

 

[Roy Green]

What was your excellent work around?

Roy

 

[Lloyd Dupont]

sorry for this late answer, I didn't touch my computer lately.

well the workaround is simple, I juste create one socket ;-)
I use a connected mode, I oen a bunch of client to my server and kept them
open and reuse them.

it runs very well and local test were twice as fast.

the coding were much longer though (there is lot of sofistication working
transparently like async read/write, auto-reconnection, message queuing and
home made thread pool ...)