FYI... I ran into an issue with some test code I wrote a few months ago,
which related to the backlog setting, as well as the annoying issue with
Winsock running out of local ports.  In my test, I was attempting to see how
many connections could be handled by a particular process over a period of
time.

I believe my results showed that increasing this value can have a very
negative effect on performance.  Basically, the issue is inherent in how the
TCP stack is implemented, not in how a particular app services the stack.  I
found that surpassing a particular connection rate threshold would result in
an exponential gain in processing time on the listening stack.  Meaning, the
TCP stack performance decreases dramatically as you increase the number of
pending connections, when the listening socket is receiving a high rate of
connection requests.  My assumption is that this is due to the increased
overhead in managing the backlog queue.  Given this, I made two
observations, which may be wrong, but made sense to me.

First, this is why the Winsock default is 5.  I imagine that the Winsock
stack implementation was designed with the perspective that if the backlog
is actually filling up enough to reach 5 or more, then something is wrong.
Probably, a couple more might be ok, but my results showed that as you
increased this value under heavy load, your connection rate was very
unpredictable, as well as instable (lots of failed connects).  For the
TCP/IP stack to be effective, it must be responsive enough to handle the low
level connection requests in a timely fashion.  If not, then you have a
major low level servicing problem or the machine is seriously overloaded
with TCP requests.  In which case, you want to get connection errors, rather
than an overloaded backlog scenario.

Second, increasing this value surely creates a greater DOS attack surface,
making you more vulnerable to bursts of socket open requests, and surely
would make the effects of such an attack even worse.  This might also be why
the Winsock default is 5.  However, as I personally don't think that there
is really a practical solution to a well designed DOS attack, then this
might not really be relevant.  Nonetheless, it might be something you need
to consider.

So, given that, I personally don't recommend increasing the value.  If your
app can't service the stack with a backlog setting close to 5, then your
system is just overloaded or not responsive for some reason.

Anyway, that is what I determined from my testing results.  If anyone has
found to the contrary, please feel free to correct me... :)

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, November 28, 2007 12:58 PM
To: twsocket@elists.org
Subject: Re: [twsocket] TWSocketServer and backlog

Hello:

The problem with retrying is that it is not the same
as a "server full" error when the maximum number of
clients is reached; 100061 is essentially a "port not
open" error, which is the same error you would get if
the server is not running.  So there is no real way
to know that the listener is currently busy and the
backlog full, or if the server is listening on a
different port or disabled completely.

I will certainly increase the backlog on my server,
but will also consider building a number of retries
in the connection routine of the client class.

   Thanks for the help.
     -dZ.



>------- Original Message -------
>From    : Wilfried
Mestdagh[mailto:[EMAIL PROTECTED]
>Sent    : 11/28/2007 2:26:49 PM
>To      : twsocket@elists.org
>Cc      : 
>Subject : RE: Re: [twsocket] TWSocketServer and backlog
>
 >Hello dz,

a client application should do at least a few (or
infinity) retry's if
connection fails. so normally not needed to increase
it. On the other
hand it does no harm to increase it.

---
Rgds, Wilfried [TeamICS]
 http://www.overbyte.be/eng/overbyte/teamics.html 
 http://www.mestdagh.biz 

Wednesday, November 28, 2007, 18:27, [EMAIL PROTECTED] wrote:

> Hello:
>     While stress-testing my application, I noticed
> that I am able to send substantially many more
> connections in the time it takes the TWSocketServer
> to handle the incomming requests, causing the default
> backlog to fill up quickly.  Obviously, I can
> increase the number, but seeing that the default is 5
> (which seems rather low to me), I'm thinking that
> perhaps there may be a concern in setting this too
high.

>     Does anybody know what I should take into
> consideration before changing this value, and if
> there are any concerns with it being too high?

>     Thanks,
>     -dZ.


-- 
To unsubscribe or change your settings for TWSocket
mailing list
please goto 
http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket

Visit our website at  http://www.overbyte.be 


-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be












































































































-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to