Re: Problem with BackLog (TCP Queue)..

First of all thanks for taking the time to respond.. I have some comments
below.

"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.t4kn99s48jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
My recollection is that the operation system has its own maximum backlog
value. Trying to set the backlog above this value will result in either
no effect, or setting to the maximum value. In neither case will you get
the backlog you're asking for.

Doesn't that defeat the purpose of the call? I assume this is like
Affinity.. The OS has one setting, but you can override that with an API
for a specific application. The API doens't change the settings permanent,
but it does for the life of the application and that application only.

One suggestion: in the code you posted, rather than having a thread sit
and loop calling BeginAcceptSocket() over and over, just have the
EndAcceptSocket() callback call it (and do so right away). The way the
code is written now, you are guaranteed a thread switch between accepting
one socket and being ready to accept another, and then of course another
thread switch to accept the next one again. This is going to
unnecessarily inhibit your throughput, artificially reducing the number of
simultaneous connection requests you can process.

I'll look deeper into this, but I got this info from MS.
http://msdn2.microsoft.com/en-us/library/system.net.sockets.tcplistener.beginacceptsocket.aspx

You have other performance-hindering design choices there as well:

* your accept callback really should be doing very little. If you
have some heavyweight processing you want to do when accepting a client,
you should handle that elsewhere if handling a large number of
simultaneous connections is a priority for you. Otherwise, you get stuck
with a thread that's doing something other than accepting connections.

I'm assuming you mean my MyWebServer.AddConnection() call. That's doing
nothing but checking current connections < max connection, then incriment a
counter.

* You should not be creating a new thread for each connection. Use
the async i/o methods for the Socket class instead (e.g. BeginReceive).
Using a thread for each connection you will unnecessarily limit the
maximum number of connections you can handle -- the number of threads any
given process can create is much lower than the number of sockets a
process could theoretically handle -- and at the same hurt performance
because of the constant thread context switches that will be required to
deal with multiple active connections.

The thread I'm creating is after I've released the callback. In VC++ I've
tested a spawn of over 2000 threads, your saying in C# that isn't possible?
Based on the examples I've seen with using BeginReceive() it's holding the
receive open longer than I currently am. But I'll look deeper and see if I
can find some better examples.


.

Relevant Pages

  • Re: Basic SocketServer & Thread Question
    ... Right now I have one instance of ServerSocket accepting connections from all client IP ... Socket s = serverSocket.bind); ).start; // process stream in a new thread}} ...
    (comp.lang.java.programmer)
  • throttling iocp threads in async server
    ... I'm designing an async socket server and I've read that the IOCP thread pool ... threads by only allowing up to MAX connections to be accepted at any given ... accepting a new connection increments N and closing an accepted socket ...
    (microsoft.public.dotnet.framework)
  • Re: Non-paged memory
    ... some sort of limit when creating about 350 tcp connections with a ... That's a way, way big backlog, by the way. ... backlog when you're not fast enough accepting connections. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Inbound connections limit in Windows XP
    ... > backlog" is fixed to 3 entries. ... single TCP server socket on which it accepts connections ... > Of course this is only an issue if you have big surges of new ... four clients, ...
    (borland.public.delphi.non-technical)
  • Re: what does backlog parameter to listen do?
    ... Though does not make 'backlog' very ... Our application is supposed to accept only 5-10 connections and then ... Closing listener works pretty well. ... our channel this way :-The quick fix solution was not to bring up ...
    (comp.os.linux.development.apps)
Loading