Limit number of connections started per listener

[SeanTAllen]

Currently, a listener will create a new connection each time there's a new connection. Allowing a limit to be set to avoid overusing resources should be added.

• TCPListener constructors need to allow for a limit (i think it makes sense to require on, rather than having the default be infinity - but we could use limit = 0 as infinity)
• TCPListener._accept is where that currently would need to go for main logic
• When TCPConnection is started from a listener, it needs to get a reference to the listener so it can inform the listener when it shuts down
• TCPConnection needs to inform the listener that started it when it shutsdown
• TCPListener needs to keep track of open connections. adding for each new one created, removing when one shuts down

Open question:

What do we do with new connection requests while at the limit?

• 1: Queue them and when we drop below the limit, spawn from queue
• 2: Reject the connection

[damon-kwok]

What do we do with new connection requests while at the limit?

• Close the listener (connections will not be affected). When the number of existing connections falls below the limit, please open the listener again.

[SeanTAllen]

@damon-kwok The standard thing to do with TCP applications when the connection limit is hit is to not accept the connection. There's only 1 listener. There's an accept queue that the connector experiences as a delay eventually when the accept queue is too high, the connection is simply rejected.

This is handle at the networking stack level. From the listener level, this change is a matter of setting the number of active connections to allow and the stack handles the rest.

[damon-kwok]

In the production environment, I often encounter attacks, lots of malicious connections. My usual practice is not only to close the socket of the listener but also to automatically replace it with a new port from time to time.
We don't need to implement what I said, just keep the flexibility at the interface level.