TCP connect() - Error WSAEADDRINUSE when traffic is heavy

TCP connect() - Error WSAEADDRINUSE when traffic is heavy

Post by Axel Mamme » Wed, 26 Jun 2002 00:22:44



I am writing a TCP Socket server that has to support 100 simultaneous
connecting clients. This means that the 100 clients will simultaneously do a
connect() and the server has to accept the connections gracefuly without
dropping anybody. I am using Windows XP Pro.

To test my server I wrote a test application that creates 100 threads, which
wait for a signal to start.
After creating the threads, the main loop signals them to start connecting.
Each thread does 100 connect/shutdown sequences and exits.
After all the threads are finished, the program prints the test results.

My problem is that sometimes connect() is unable to complete and
WSAGetLastError() returns WSAEADDRINUSE.
According to the documentation this is a bind problem, but I'm not doing a
bind() on the client side, which in theory is done automatically when the
connection is successful.

This does not happen if I reduce the amount of threads to 10.

Can this be happening due to a bug in connect( ) using an unbinded socket?
Does connect() protect itself correctly against race conditions?
Maybe several simultaneous connects() are trying to reserve the same port,
and only one succeeds.
How would setsockopt( SO_REUSEADDR ) affect this behaviour?
Would this disappear if I bind the socket before issuing the connect()
command?
Are ConnectEx and AcceptEx and overlapped I/O necessary for this type of
performance or are connect() and accept() good enough?

Best regards,
Axel

 
 
 

TCP connect() - Error WSAEADDRINUSE when traffic is heavy

Post by Slava M. Uso » Wed, 26 Jun 2002 01:40:01




Quote:> I am writing a TCP Socket server that has to support 100 simultaneous
> connecting clients. This means that the 100 clients will simultaneously do
> a connect() and the server has to accept the connections gracefuly without
> dropping anybody. I am using Windows XP Pro.

[...]

Quote:> My problem is that sometimes connect() is unable to complete and
> WSAGetLastError() returns WSAEADDRINUSE.

[...]

Quote:> This does not happen if I reduce the amount of threads to 10.

[...]

Most likely, your server is not quick enough to issue accept calls and the
"backlog" queue is too short to keep all the not-yet-accepted connections.

Quote:> Are ConnectEx and AcceptEx and overlapped I/O necessary for this type of
> performance or are connect() and accept() good enough?

You will most likely have to use AcceptEx() with a number of pre-created
sockets so that the incoming connections are not dropped even if you cannot
process them as fast as they come. You might also experiment with the
backlog setting when you call listen() -- I do not remember, though, if long
backlogs are supported for non-server NT versions.

Speaking of overlapped IO, you will most certainly need it, as having one
thread per client is not a good idea for a large number of clients.

S

 
 
 

TCP connect() - Error WSAEADDRINUSE when traffic is heavy

Post by Axel Mamme » Wed, 26 Jun 2002 02:03:22


Even if my server is too slow to accept all the incoming connections, it
makes no sense for connect() to be returning WSAEADDRINUSE. BTW, the
connection backlog setting is SOMAXCONN. I still think there's a bug in
connect() or in accept().

I found a great tutorial and source code on high performance socket servers
here:
http://www.jetbyte.com/portfolio-showarticle.asp?articleId=37&catId=1...
Id=2

and here:
http://www.jetbyte.com/portfolio-showarticle.asp?articleId=39&catId=1...
Id=2

Best regards,
Axel





> > I am writing a TCP Socket server that has to support 100 simultaneous
> > connecting clients. This means that the 100 clients will simultaneously
do
> > a connect() and the server has to accept the connections gracefuly
without
> > dropping anybody. I am using Windows XP Pro.

> [...]

> > My problem is that sometimes connect() is unable to complete and
> > WSAGetLastError() returns WSAEADDRINUSE.

> [...]

> > This does not happen if I reduce the amount of threads to 10.

> [...]

> Most likely, your server is not quick enough to issue accept calls and the
> "backlog" queue is too short to keep all the not-yet-accepted connections.

> > Are ConnectEx and AcceptEx and overlapped I/O necessary for this type of
> > performance or are connect() and accept() good enough?

> You will most likely have to use AcceptEx() with a number of pre-created
> sockets so that the incoming connections are not dropped even if you
cannot
> process them as fast as they come. You might also experiment with the
> backlog setting when you call listen() -- I do not remember, though, if
long
> backlogs are supported for non-server NT versions.

> Speaking of overlapped IO, you will most certainly need it, as having one
> thread per client is not a good idea for a large number of clients.

> S

 
 
 

TCP connect() - Error WSAEADDRINUSE when traffic is heavy

Post by Len Holgat » Wed, 26 Jun 2002 04:52:44


Alex,

Once your test client starts to fail does it fail for a certain amount of
time and then stop failing, or are the failures randomly distributed? Are
the real client connections likely to be this short lived? If not, try
testing with more realistic connection durations.

I'm guessing here but, your problem may be due to the closed connections
sitting in the time wait state and due to the number of connections you're
establishing and shutting down you're running out of available port numbers
to reuse for the client end of the connection.  I don't really fully
understand this part of how TCP connections work though. Run netstat and see
what it says... Try running two clients using half the resources from two
different machines.

Glad you found the articles on our web site useful.

--
Len Holgate
http://www.jetbyte.com
The right code, right now.
Contract Programming and Consulting Services.

 
 
 

TCP connect() - Error WSAEADDRINUSE when traffic is heavy

Post by Axel Mamme » Thu, 27 Jun 2002 03:14:10


Len,

I also suspected that I was running out of sockets, so I rebooted my PC and
the test results were the same.

If I run my process with REALTIME priority I get 5 times more connection
errors than running a IDLE priority. I suppose my process is interrupting
too frequently. Anyway this shouldn't happen since this means that if you
have a realtime process running using TCP, the network subsystem becomes
unstable.

Do you know if there is a way to avoid TIME_WAIT? I am doing graceful
disconnections on the client side, so this shouldn't be happening.

Best regards,
Axel

Quote:

> Once your test client starts to fail does it fail for a certain amount of
> time and then stop failing, or are the failures randomly distributed? Are
> the real client connections likely to be this short lived? If not, try
> testing with more realistic connection durations.

> I'm guessing here but, your problem may be due to the closed connections
> sitting in the time wait state and due to the number of connections you're
> establishing and shutting down you're running out of available port
numbers
> to reuse for the client end of the connection.  I don't really fully
> understand this part of how TCP connections work though. Run netstat and
see
> what it says... Try running two clients using half the resources from two
> different machines.

> Glad you found the articles on our web site useful.

> --
> Len Holgate
> http://www.jetbyte.com
> The right code, right now.
> Contract Programming and Consulting Services.

 
 
 

TCP connect() - Error WSAEADDRINUSE when traffic is heavy

Post by Phil Ashb » Thu, 27 Jun 2002 23:08:19


Silly point - but will the real system have one client creating lots of
connections, ie: do you have to solve this client problem?

--
Phil "Phlash" Ashby (speaking only for himself)
Work: http://www.internet-designers.net/
Home: http://www.ashbysoft.com/

 
 
 

1. TCP/IP stack failure under Windows 2000 and heavy UDP traffic.

I've written some code that relies totally on UDP for sending data between computers.  The protocol has
similar characteristics as RTP but hopefully faster and more streamlined since it only does what I need it to do.
The problem comes in under Windows 2000 - After a certain period of time (different for each run) of around 20 hours
the entire TCP/IP stack will go down silently.  Absolutely NO application will be able to communicate using TCP or UDP
at all after this point and only a reboot will fix it.  It seems to be a problem on both Pro and Advanced Server and may have
something to do with Office 2000.

This problem does not show up under NT4 or Windows 9x as they will run for weeks on end under the same circumstances
without fail.

Has anyone run into this?  THe only other way I know of to test it would be to use something like Media Player
or RealPlayer but neither really stress test like my application does.  The closest thing to it would be to run a
Media Server on one system and about 50 clients on another server all viewing the same content at full LAN
speeds.

Even a lower stress level still causes the TCP/IP stack to go down eventually.  However, web surfing and email
don't appear to effect it, so I'm assuming there is a problem with my code, but it only shows up under Win2k.

Any ideas?

2. 1 col title on 2 col page

3. WSAEADDRINUSE error on connect()?

4. Xircom RealPort Ethernet/56k card

5. WSAEADDRINUSE error on connect()

6. need mortage qualifying spreadsheet

7. Heavy download traffic

8. TTFs language/endcoding editor

9. connect() returns WSAEADDRINUSE ??? Hi all,

10. do heavy background process affect tcp data transfer?

11. WSAEADDRINUSE error

12. WSAEADDRINUSE error, but....

13. WSAEADDRINUSE Error Question