[ back to toc ]

Listening to a socket

Date: 2001/12/14 20:36

Hi Peter:

I am writing a service for Windows NT environment using Visual Studio 6.0

Going from basic tutorials, I have come across the standard algorithm:

void main(void) {

//Init Winsock
//Create server socket
//Fill in socket structure with address information
//Bind socket with local address
//Listen to port

//this loop makes the server concurrant
//Create client socket and wait for connection
//Accept client connection
//Spawn thread to Send/Receive information from client

//close server socket
//Winsock cleanup

What I am confused with is the listen function. It's prototype is this:

int listen(int s, int backlog) - and backlog specifies the maximum number
of outstanding connection requests in listen()'s input queue.

I still don't quite understand what this means. I have my program already
written using the previous pseudocode, and let's say I set my maximum
number of connections to 3. However, I still can connect to my service
more than 3 times. I don't even understand why I need to specify a
maximum number if the server is going to spawn worker threads to take care
of the job leaving my server free to accept another connection.

Does the maximum number mean how many clients can connect at the *exact*
moment in time?

Also, can you see any flaws in this algorithm? I want to write is a
service that connects to a SQL Server given username/password. I have
heard about drawbacks between asynchronous and synchronous services (I
have no idea as what my algorithm belongs to).

Thanks for any input and advice!

The number of concurrent connections you serve is up to your program and
has nothing to do with listen backlog.

The listen backlong is the number of connections that are handled by the
listening socket concurrently. This is a waiting queue that you take the
connections from when you "accept" a connection. This should be greater th
an the number of connections that may come to the server during the time
you "accept" the connection, create a thread to handle that connection and
return the program loop to the listen. This is an extremely small time,
because it is not likely that the processor switches context between this.
The new thread to handle the created process is created by the program,
but it does not starts immediately. The actual thread has its timeslice
and continues running. If there are connection requests waiting in the
listen queue having the length of not more than backlog then the loop gets
it and loops again. If there is no waiting connection then the looping
thread looses the time slice and another thread starts.

On an advertisement engine that handles today 3million banners a day the
backlog value 3 (three) is doing fine.

>can connect at the *exact* moment in time

This is only one, for the sole reason that Ethernet packet collision if
this is Ethernet. If this is not Ethernet but some other non collision
detect network then there can not be more than one connect at a time on a
socket (unless you bind a socket to more than one interface that you can
also do). OK you can have more simultaneous connections, but this is not
what you really was tinking of.

Lets say sloppily that backlog is the number of simultaneous connections
that come in a very short time.

>Also, can you see any flaws in this algorithm?

No. This is the usual approach.

>I have heard about drawbacks between asynchronous and synchronous
services (I have no idea as what my algorithm belongs to).
>//Spawn thread to Send/Receive information from client

You answer your own question. Your algorithm is asyncronous. Take care of

To get some program to read visit www.scriptbasic.com This is a BASIC
interpreter (I am not going to fool you, calm). There are two
implementations on the site of the core interpreter. One is a standalone
executable. That is not interesting for you. The other one is a simple
webserver that can also be installed on NT as a service. This may provide
you some example on handling server sockets.


[ back to toc ]