Re: listen returns no errors, but doesn't appear to be listening

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Alexander Nickolov (agnickolov_at_mvps.org)
Date: 11/17/04 

Date: Wed, 17 Nov 2004 00:49:07 -0800

You need only _one_ socket bound to listen on. Then
have a thread that does the accepting business only.
It'll spawn a worker thread (or use a thread pool) to
assign the accepted socket for processing, then
continues to listen on the original socket. Note, if you
use non-blocking sockets, you won't need a thread
per socket as each thread can service up to 64
non-blocking sockets (via select, or WSAEventSelect,
or event-based overlapped I/O). With async sockets
(e.g. Windows messages via WSAAsyncSelect) you
can service even more sockets on a single thread.
The ultimate performance is achieved with a thread
pool using overlapped I/O and I/O completion ports. 

-- 
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"DBard" <DBard@discussions.microsoft.com> wrote in message 
news:E6A2B41B-377C-4475-A560-AA5E04A6A483@microsoft.com...
> Thanks - now please let me be clear.
>
> I can change my approach to put a bunch of socket handles in an array.  I
> can see maybe several hundred sockets staying connected to the application 
> at
> a times.
>
> The first time a thread runs for a socket, I will create the socket and 
> bind
> to it.  Then it will listen, accept and communicate as normal.  After the
> client closes the socket, I will not close the server socket, but just end
> the thread.
>
> The next time a thread on that particual socket needs to listen, I just
> launch a thread (as I do now) and then just call the listen function on 
> that
> socket (skipping the socket and bind functions).
>
> Make sense?  Is there a maxiumum number of sockets which can be 
> concurrently
> launched on the same TCP port number?  I thought that's why SO_REUSEADDR 
> was
> needed.
>
> Thanks.
>
> "Alexander Nickolov" wrote:
>
>> You are essentially leaking socket handles. When you accept,
>> the original socket continues to exist. You should not open
>> new sockets at this point - just have your new thread start
>> listening on the old socket. You won't need SO_REUSEADDR
>> either.
>>
>> -- 
>> =====================================
>> Alexander Nickolov
>> Microsoft MVP [VC], MCSD
>> email: agnickolov@mvps.org
>> MVP VC FAQ: http://www.mvps.org/vcfaq
>> =====================================
>>
>> "DBard" <DBard@discussions.microsoft.com> wrote in message
>> news:11BCED27-F738-4534-BB9C-32737299F331@microsoft.com...
>> >I have a threaded socket server program which seems to get "stuck" with 
>> >a
>> > thread in the listening state, but which nothing is able to connect to.
>> >
>> > The program launches a thread which creates a socket (using socket), 
>> > calls
>> > setsockoption (SO_REUSEADDR), binds, listens, accepts, sends data back 
>> > and
>> > forth, etc.  After a thread's socket transitions to the connected state
>> > (accept succeeded) the main program launches another thread to do the 
>> > same
>> > thing.
>> >
>> > This all works pretty well for a handful of connections, then ends up
>> > getting to a point where listen is called (no errors returned), but no
>> > client
>> > is able to connect to the socket anymore.
>> >
>> > This may take a few rounds of idea exchange here to narrow it, but can
>> > anyone offer up any beginning ideas of what to look for?
>> >
>> > Thanks.
>> >
>> > - Dave
>>
>>
>>

Relevant Pages

  • Re: !EventConnect Problem
    ... the June roll-up is available somewhere, although there's not been the usual ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Re: !EventConnect Problem
    ... the June roll-up is available somewhere, ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Re: !EventConnect Problem
    ... poll time of 500mS we get a break in communication approx once a day, ... The socket is not in a listening state. ... There's a problem with the connection address, ...
    (microsoft.public.windowsce.app.development)
  • Re: !EventConnect Problem
    ... You'll probably want to know whether the socket ... server we are using is multi-threaded, however this only seens to have ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Re: !EventConnect Problem
    ... you're going to have to contact MS and use one of the Platform Builder ... You'll probably want to know whether the socket is ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)