On 9 December 2012 12:31, Miha Valencic email@example.com wrote:
Let me say upfront, that I'm not seeing any problems as of now. I am asking this question out of engineering curiosity mostly and to know whta to do if the problem would arose.
On Sun, Dec 9, 2012 at 10:44 AM, Adi Roiban firstname.lastname@example.org wrote:
Hi, Just to summarize:
- twisted.protocols.policies.LimitTotalConnectionsFactory is not what
you want since the server is still listening on the port? LimitTotalConnectionsFactory is only returning a different protocol to handle the overflow.... closing the new connection is a way to handle the overflow.
I've never heard of LimitTotalConnectionsFactory before. This particular mode of operation is desirable, since the client is connected and disconnected. I was aiming more towards a usual approach within webservers, where they have a certain amount of tcp workers, and size of the waiting queue. That way the client does not get disconnected, but waits a little and then gets a result. You know how to webserver sometimes times out...
But, really, thinking about it, this factory is the right after all. Akin to "http 550 service unavailable" when the service is not able to respond to requests. If I understand the description correctly, defining custom protocol that write "unavailable" and closes connection, setting this protocol as a overflowProtocol would have the exact behaviour I am after.
Yes. You can implement a simple HTTP protocol which always returns 503 or some other code.
- After a number of connections the server should stop listening on
the port... and then tor re-start listening after the connections are closed?
No, the server shouldn't accept() the socket after n connections are opened(). But see previous paragraph.
I think that we are talking about different "accepts", but LimitTotalConnectionsFactory should do your job.