search

sysapps / tcp-udp-sockets

Raw sockets API
85 stars 25 forks source link

Defining TCPServerSocket backlog (maximum number of connection requests) #45

Open ClaesNilsson opened 11 years ago

ClaesNilsson commented 11 years ago

[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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

Ke-Fong, do you have more information here?

Should we add the following to dictionary TCPServerOptions ?