ServerSocket vs ServerSocket2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ServerSocket vs ServerSocket2

Sean Malloy-11
Can anyone riddle me this:

Why does ServerSocket outperform ServerSocket2 when the backlog size is low
(5), but the ServerSocket2 outperform ServerSocket when the backlog is high
(50+)

I'm a relative newbie when it comes to Socket programming... I realise the
basic difference between the two, in that Socket use async messages/windows
message pump to do process, and Socket2 does not. If someone could spell out
the why for me? I have some guesses, but I don't want to out myself as a
complete idiot

(Well I've already done that a few times....)


Reply | Threaded
Open this post in threaded view
|

Re: ServerSocket vs ServerSocket2

Chris Uppal-3
Sean,

> Why does ServerSocket outperform ServerSocket2 when the backlog size is
> low (5), but the ServerSocket2 outperform ServerSocket when the backlog
> is high (50+)

I have no idea at all.  I find it very surprising that there is any difference
since the backlog parameter (as far as I know) is only used by Windows to set
the size of the queue of inbound connections that /it/ has "accepted" (i.e. not
actively rejected) but has not yet been able to tell Dolphin about.  Under the
cicumstances its difficult to see how the implementation in Dolphin makes any
difference since (by definition) that implementation has not yet got involved
in processing the request.  How are you doing the test ?  Maybe there's some
other interaction going on ?

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: ServerSocket vs ServerSocket2

Schwab,Wilhelm K
Chris, Sean,

>>Why does ServerSocket outperform ServerSocket2 when the backlog size is
>>low (5), but the ServerSocket2 outperform ServerSocket when the backlog
>>is high (50+)
>
>
> I have no idea at all.  I find it very surprising that there is any difference
> since the backlog parameter (as far as I know) is only used by Windows to set
> the size of the queue of inbound connections that /it/ has "accepted" (i.e. not
> actively rejected) but has not yet been able to tell Dolphin about.  Under the
> cicumstances its difficult to see how the implementation in Dolphin makes any
> difference since (by definition) that implementation has not yet got involved
> in processing the request.  How are you doing the test ?  Maybe there's some
> other interaction going on ?

Search for JAWS (the pluggable web server, not the rubber shark<g>) and
see what you think.  Your example might fit one of the categories where
there is a difference; remember that overlapped calls are switched by
Microsoft programmers in other processes, but green threads switch
courtesy of Blair's VM in the same OS process - need I say more? :)
Read the papers and see what you think.  IMHO, it makes a very good
argument to keep both types of sockets around, letting folks choose
based on profiling or preference.  One could even leave it up to the end
user.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]