Defining TCPServerSocket backlog (maximum number of connection requests)

[ClaesNilsson]

[Patrick]

• some folks will question why the server socket API doesn't contain a
  backlog attribute that corresponds to the listen() system call that is
  traditionally part of the socket API

[Ke-Fong]: Yes, it should be added.

[Claes] If I remember correctly it was said that the maximum number of connection requests that can be queued before the system starts rejecting incoming requests should not be controllable by web applications. But this might be a mistake so the attribute can easily be added if required.

[ClaesNilsson]

node.js has a backlog argument in the server.listen() method: http://nodejs.org/api/net.html#net_server_listen_port_host_backlog_callback

Do we need a maxConnections field in TCPServerOptions? Compare with: http://nodejs.org/api/net.html#net_server_maxconnections

[anotherlin]

I have to double check that but the "backlog" of listen() is actually quite vague. The backlog includes both the number of "really" connected client(s) which socket can be returned by a call to accept(). And the client(s) currently in the process of connecting (three steps opening handshake).

This is really system dependent. So in my opinion, yes we should have this argument, but add a note that this implementation dependent. Or there may be a system dependent way to specify the backlog in a more precise way than listen(). We should investigate that.

NodeJS's server.maxConnections should be same as the backlog number. Once a socket is retrieved from accept() it is the server's user code responsibility, which should drop it if necessary.

[ClaesNilsson]

Ke-Fong, do you have more information here?

Should we add the following to dictionary TCPServerOptions ?

• backlog of type unsigned short
  The maximum length of the queue of pending connections. The actual length will be determined by your OS. Deafult is 511.
• maxConnections of type unsigned short
  The maximum number of server connections.. Default ?