MK27

Is the second argument to listen to limit the number of connect requests pending, or the total number of connections? I presume the former, since it certianly does not restrict the later with a LOCAL socket. Why/how could a program ever end up with such a queue, since a socket set to listen seems to "accept" a connection as the request is recieved?

Does this also mean that to truly limit the number of connections, a routine must exist to close them as soon as they are made beyond a certian number, or close the listening socket?

__________________

"A man can't just sit around." -- Larry Walters

robwhit

Imagine multiple clients trying to connect to a server at once. If the requests come in faster than the server can accept() them, then the listen queue fills. Up. When you accept() a connection from a socket that is listening, it removes the entry for that connection from the queue.

MK27

Just wanted to clarify for myself that this is the purpose of accept() and not to perform some possible filtering action (if (incoming==okay) accept), and that the queue is NOT the "maximum number of connections".

I'm guessing this is one way a server gets "flooded" -- the CPU clocks out handling the queue. On second thought, even if the queue is full I imagine it won't take much to just "deny" (is that an action, or a socket status detectable by connect?) and accept one by one.

__________________

"A man can't just sit around." -- Larry Walters

robwhit

> Just wanted to clarify for myself that this is the purpose of accept()

accept accepts a socket from a listen queue from a listening socket.

> and not to perform some possible filtering action (if (incoming==okay) accept),

I don't know how you could direct accept to filter connections.

> and that the queue is NOT the "maximum number of connections".

I am almost completely sure that the listen queue is not the maximum number of connections, and you typically set it to some low number.

> I'm guessing this is one way a server gets "flooded" -- the CPU clocks out handling the queue. On second thought, even if the queue is full I imagine it won't take much to just "deny" (is that an action, or a socket status detectable by connect?) and accept one by one.

Yes, that's one way. Some stacks don't even refuse the connection, they just drop it.