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(endPo int);

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()
(NativeErrorCod e: 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]]

Re: Socket bug

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

--
Greg Ewing [MVP]

http://www.citidc.com/

"Lloyd Dupont" <net.galador@ld > wrote in message
news:OJECfl0jDH A.2616@TK2MSFTN GP11.phx.gbl...[color=blue]
> 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(endPo int);
>
> 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)[/color]
I[color=blue]
> have a socket exception on Connect()
> (NativeErrorCod e: 10048, only one socket could listen at a given
> address/port) ???
> It's a client socket, and I don't bind it at all !!!
>
>[/color]

[_]

Re: Socket bug

On Sat, 11 Oct 2003 02:12:59 +1000, "Lloyd Dupont" <net.galador@ld > wrote:
[color=blue]
> s.Close();[/color]

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

https://www.abderaware.com

zane @at@ abderaware .dot. com

[Ron Alberda [MSFT]]

Re: Socket bug

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.Threadin g.Thread.Sleep for ~2 minutes when
you get close to 1000 connections.

-Ron

"Lloyd Dupont" <net.galador@ld > wrote in message
news:ulDvoT5jDH A.2244@TK2MSFTN GP12.phx.gbl...[color=blue]
> here you go, the stress client and server.
> compile with:
> csc /nologo /out:client.exe StressTest.cs StressClient.cs
> csc /nologo /out:server.exe StressTest.cs StressServer.cs
>
> and run server & client in 2 different console, although I would advise[/color]
you[color=blue]
> to run client with a debugger, to catch the exception.
>
> when I run client multiple time it bug, randomly, about every second
> times....
>
> "Greg Ewing [MVP]" <gewing@_NO_SPA M_citidc.com> a écrit dans le message de
> news:OaUDDE2jDH A.1488@TK2MSFTN GP12.phx.gbl...[color=green]
> > Lloyd, could you post a working, simple sample which demonstrates what[/color][/color]
you[color=blue][color=green]
> > are seeing? A simple command line app would be perfect.
> >
> > --
> > Greg Ewing [MVP]
> > http://www.citidc.com/
> >
> >
> >
> > "Lloyd Dupont" <net.galador@ld > wrote in message
> > news:OJECfl0jDH A.2616@TK2MSFTN GP11.phx.gbl...[color=darkred]
> > > 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(endPo int);
> > >
> > > 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[/color][/color]
> always)[color=green]
> > I[color=darkred]
> > > have a socket exception on Connect()
> > > (NativeErrorCod e: 10048, only one socket could listen at a given
> > > address/port) ???
> > > It's a client socket, and I don't bind it at all !!!
> > >
> > >[/color]
> >
> >[/color]
>
>
>[/color]

[Lloyd Dupont]

Re: Socket bug

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

"Ron Alberda [MSFT]" <ronalda@online .microsoft.com> a écrit dans le message
de news:efMUxVCmDH A.2964@tk2msftn gp13.phx.gbl...[color=blue]
> This is a known issue. You are running out of "wildcard" ports. When you[/color]
do[color=blue]
> 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[/color]
the[color=blue]
> 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[/color]
notice[color=blue]
> the socket Exception you'll see lots of connections in the "TIME_WAIT"
> state.
>
> The workaround is to do a System.Threadin g.Thread.Sleep for ~2 minutes[/color]
when[color=blue]
> you get close to 1000 connections.
>
> -Ron
>
> "Lloyd Dupont" <net.galador@ld > wrote in message
> news:ulDvoT5jDH A.2244@TK2MSFTN GP12.phx.gbl...[color=green]
> > here you go, the stress client and server.
> > compile with:
> > csc /nologo /out:client.exe StressTest.cs StressClient.cs
> > csc /nologo /out:server.exe StressTest.cs StressServer.cs
> >
> > and run server & client in 2 different console, although I would advise[/color]
> you[color=green]
> > to run client with a debugger, to catch the exception.
> >
> > when I run client multiple time it bug, randomly, about every second
> > times....
> >
> > "Greg Ewing [MVP]" <gewing@_NO_SPA M_citidc.com> a écrit dans le message[/color][/color]
de[color=blue][color=green]
> > news:OaUDDE2jDH A.1488@TK2MSFTN GP12.phx.gbl...[color=darkred]
> > > Lloyd, could you post a working, simple sample which demonstrates what[/color][/color]
> you[color=green][color=darkred]
> > > are seeing? A simple command line app would be perfect.
> > >
> > > --
> > > Greg Ewing [MVP]
> > > http://www.citidc.com/
> > >
> > >
> > >
> > > "Lloyd Dupont" <net.galador@ld > wrote in message
> > > news:OJECfl0jDH A.2616@TK2MSFTN GP11.phx.gbl...
> > > > 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(endPo int);
> > > >
> > > > 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[/color]
> > always)[color=darkred]
> > > I
> > > > have a socket exception on Connect()
> > > > (NativeErrorCod e: 10048, only one socket could listen at a given
> > > > address/port) ???
> > > > It's a client socket, and I don't bind it at all !!!
> > > >
> > > >
> > >
> > >[/color]
> >
> >
> >[/color]
>
>[/color]

[Roy Green]

Re: Socket bug

What was your excellent work around?

Roy

"Lloyd Dupont" <net.galador@ld > wrote in message
news:u3cRTC5mDH A.1676@TK2MSFTN GP09.phx.gbl...[color=blue]
> ho, ok.
> thanks for the info.
> I had an excellent work around since then, anyway ;-)
>
>[/color]

[Lloyd Dupont]

Re: Socket bug

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 ...)

"Roy Green" <roygreen@minds pring.com> a écrit dans le message de
news:u0ivPLvnDH A.3612@TK2MSFTN GP11.phx.gbl...[color=blue]
> What was your excellent work around?
>
> Roy
>
> "Lloyd Dupont" <net.galador@ld > wrote in message
> news:u3cRTC5mDH A.1676@TK2MSFTN GP09.phx.gbl...[color=green]
> > ho, ok.
> > thanks for the info.
> > I had an excellent work around since then, anyway ;-)
> >
> >[/color]
>
>[/color]