[Twisted-Python] Limiting the number of connections
Hi! I have developed a simple twisted tcp server which does ldap lookups as a result of user input. I would like to limit the number of connections each listener (I have 4, each on its own port) accepts. I guess people usually want to accept as many connections as possible, but I would like to limit them.
Is this still the case? We can't limit the number of accepted connections? Regards, Miha.
Hi, On 9 December 2012 02:17, Miha Valencic <miha.valencic@gmail.com> wrote:
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. * After a number of connections the server should stop listening on the port... and then tor re-start listening after the connections are closed? Cheers, -- Adi Roiban
Hi Adi! 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 <adi@roiban.ro> wrote:
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.
No, the server shouldn't accept() the socket after n connections are opened(). But see previous paragraph. Regards, Miha.
On 12/09/2012 05:31 AM, Miha Valencic wrote:
No, the server shouldn't accept() the socket after n connections are opened(). But see previous paragraph.
You can stop accept()ing by calling stopReading() on the returned port object: port = reactor.listenTCP(....) port.stopReading() And start again by calling startReading(). However: - When you are accept()ing, it will accept() a few at a time. - Even if you stop accept()ing, the OS will still do TCP handshakes, approximately up to a limit determined by one of the arguments passed to listenTCP. - After hitting the limit, clients will get connection refused, IIRC. In general it's better to do a protocol-level solution, as Adi Roiban suggested.
On 9 December 2012 14:57, Itamar Turner-Trauring <itamar@itamarst.org> wrote:
Many thanks for you explanation. Checking the documentation I can read that reactor.listenTCP returns an IListeningPort [1] Checking IListeningPort I can read that it has no stopReading() , startReading() methods [2] Can you please advise how and when to use startReading vs startListening ? Many thanks! [1] http://twistedmatrix.com/documents/12.2.0/api/twisted.internet.interfaces.IR... [2] http://twistedmatrix.com/documents/12.2.0/api/twisted.internet.interfaces.IL... -- Adi Roiban
On 12/09/2012 08:14 AM, Adi Roiban wrote: the interface is, though perhaps not on IOCP, or some other hypothetical future reactor. startListening() does the opposite of stopListening(), it's completely different than stop/startReading - the former pair are permanent 'open or close the socket', vs. the latter 'unregister socket from event loop temporarily'. In any case, as I said, doing stopReading() on a TCP port is not particularly useful, much better to handle it in factory and protocol level.
On 9 December 2012 15:14, Adi Roiban <adi@roiban.ro> wrote:
I would like to rephrase my previous question: I understood that stopListening() is closing the listening socket, while stopReading does not closed the listening socket, but rather stops from handling new connection using the attached factory ... and new connections are queued in the backlog. What interfaces defines startReading/stopReading for a TCP Port? Thanks! -- Adi Roiban
On 9 December 2012 12:31, Miha Valencic <miha.valencic@gmail.com> wrote:
Yes. You can implement a simple HTTP protocol which always returns 503 or some other code.
I think that we are talking about different "accepts", but LimitTotalConnectionsFactory should do your job. Cheers -- Adi Roiban
Hi, On 9 December 2012 02:17, Miha Valencic <miha.valencic@gmail.com> wrote:
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. * After a number of connections the server should stop listening on the port... and then tor re-start listening after the connections are closed? Cheers, -- Adi Roiban
Hi Adi! 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 <adi@roiban.ro> wrote:
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.
No, the server shouldn't accept() the socket after n connections are opened(). But see previous paragraph. Regards, Miha.
On 12/09/2012 05:31 AM, Miha Valencic wrote:
No, the server shouldn't accept() the socket after n connections are opened(). But see previous paragraph.
You can stop accept()ing by calling stopReading() on the returned port object: port = reactor.listenTCP(....) port.stopReading() And start again by calling startReading(). However: - When you are accept()ing, it will accept() a few at a time. - Even if you stop accept()ing, the OS will still do TCP handshakes, approximately up to a limit determined by one of the arguments passed to listenTCP. - After hitting the limit, clients will get connection refused, IIRC. In general it's better to do a protocol-level solution, as Adi Roiban suggested.
On 9 December 2012 14:57, Itamar Turner-Trauring <itamar@itamarst.org> wrote:
Many thanks for you explanation. Checking the documentation I can read that reactor.listenTCP returns an IListeningPort [1] Checking IListeningPort I can read that it has no stopReading() , startReading() methods [2] Can you please advise how and when to use startReading vs startListening ? Many thanks! [1] http://twistedmatrix.com/documents/12.2.0/api/twisted.internet.interfaces.IR... [2] http://twistedmatrix.com/documents/12.2.0/api/twisted.internet.interfaces.IL... -- Adi Roiban
On 12/09/2012 08:14 AM, Adi Roiban wrote: the interface is, though perhaps not on IOCP, or some other hypothetical future reactor. startListening() does the opposite of stopListening(), it's completely different than stop/startReading - the former pair are permanent 'open or close the socket', vs. the latter 'unregister socket from event loop temporarily'. In any case, as I said, doing stopReading() on a TCP port is not particularly useful, much better to handle it in factory and protocol level.
On 9 December 2012 15:14, Adi Roiban <adi@roiban.ro> wrote:
I would like to rephrase my previous question: I understood that stopListening() is closing the listening socket, while stopReading does not closed the listening socket, but rather stops from handling new connection using the attached factory ... and new connections are queued in the backlog. What interfaces defines startReading/stopReading for a TCP Port? Thanks! -- Adi Roiban
On 9 December 2012 12:31, Miha Valencic <miha.valencic@gmail.com> wrote:
Yes. You can implement a simple HTTP protocol which always returns 503 or some other code.
I think that we are talking about different "accepts", but LimitTotalConnectionsFactory should do your job. Cheers -- Adi Roiban
participants (3)
-
Adi Roiban -
Itamar Turner-Trauring -
Miha Valencic