[Twisted-Python] remove a tcp.Port
Hello, The first bug I ran into with twisted.ftp is that after 15 tcp.Ports has been opened and closed, skt.Listen starts to fail. This is due to the fact that when calling Port.loseConnection, the actual code called is Server.loseConnection which does not removeReader (actually, the Port.loseConnection is broken, since it calls removeReader and not main.removeReader). Well, there's seems to be two types of behaviour intended with the code, and of course, calling a loseConnection to the server shouldn't remove it entirely, but there should be a function doing that. Another thing, the limit for maximum Ports, where is it? And can shouldn't it be configurable? And here follows the somewhat confusing traceback. Note that this is upon re-connecting the ftp-server. When the client can't connect to the server, there's nothing on the log. 01/09/2001 18:38 [FTP,1,127.0.0.1] Traceback (most recent call last): 01/09/2001 18:38 [FTP,1,127.0.0.1] File "c:\dev\twisted\twisted\internet\main.py", line 267, in doSelect 01/09/2001 18:38 [FTP,1,127.0.0.1] why = getattr(selectable, method)() 01/09/2001 18:38 [FTP,1,127.0.0.1] File "c:\dev\twisted\twisted\internet\tcp.py", line 82, in doRead 01/09/2001 18:38 [FTP,1,127.0.0.1] return self.protocol.dataReceived(data) 01/09/2001 18:38 [FTP,1,127.0.0.1] File "c:\dev\twisted\twisted\protocols\ftp.py", line 590, in dataReceived 01/09/2001 18:38 [FTP,1,127.0.0.1] self.processLine(line) 01/09/2001 18:38 [FTP,1,127.0.0.1] File "c:\dev\twisted\twisted\protocols\ftp.py", line 583, in processLine 01/09/2001 18:38 [FTP,1,127.0.0.1] n = method(params) 01/09/2001 18:38 [FTP,1,127.0.0.1] File "c:\dev\twisted\twisted\protocols\ftp.py", line 433, in ftp_Pasv 01/09/2001 18:38 [FTP,1,127.0.0.1] self.createPassiveServer() 01/09/2001 18:38 [FTP,1,127.0.0.1] File "c:\dev\twisted\twisted\protocols\ftp.py", line 379, in createPassiveServer 01/09/2001 18:38 [FTP,1,127.0.0.1] self.dtpPort.startListening() 01/09/2001 18:38 [FTP,1,127.0.0.1] File "c:\dev\twisted\twisted\internet\tcp.py", line 297, in startListening 01/09/2001 18:38 [FTP,1,127.0.0.1] skt.listen(self.backlog) 01/09/2001 18:38 [FTP,1,127.0.0.1] File "<string>", line 1, in listen 01/09/2001 18:38 [FTP,1,127.0.0.1] error: (10055, 'No buffer space available')
On Sat, Sep 01, 2001 at 06:49:48PM +0200, Maj-Britt Bruheim wrote:
The first bug I ran into with twisted.ftp is that after 15 tcp.Ports has been opened and closed, skt.Listen starts to fail. This is due to the fact that when calling Port.loseConnection, the actual code called is Server.loseConnection which does not removeReader (actually, the Port.loseConnection is broken, since it calls removeReader and not main.removeReader).
Yeah. The socket wouldn't get closed (In fact, a traceback would prevent anything from happening at all...) , and so you'd run out of available listening sockets (15 tcp.Ports = 15 listening sockets * 5 queue entries = 75 queue entries) fairly quickly. (See below about NT...)
Well, there's seems to be two types of behaviour intended with the code, and of course, calling a loseConnection to the server shouldn't remove it entirely, but there should be a function doing that.
Both of those behaviors are necessary. Calling loseConnection on a Port means "stop accepting connections on this port" (as the documentation reads). If you were to not remove that from the select loop, some ugly behavior would result.
Another thing, the limit for maximum Ports, where is it? And can shouldn't it be configurable?
This is an OS-imposed limit, as far as I know. I can't do anything about it.
And here follows the somewhat confusing traceback. Note that this is upon re-connecting the ftp-server. When the client can't connect to the server, there's nothing on the log.
Can you reproduce this on a UNIX? Is this an NT or 95 derivative Windows you're using? I'll hazard a guess that it's NT "Workstation", which has some colorfully imposed limits on the number of sockets you can listen on. Although I don't know if 95 has the same issues. The "red hat linux installation guide" has step-by-step instructions for fixing that "bug" :-) [traceback omitted] -- ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
participants (2)
-
Glyph Lefkowitz
-
Maj-Britt Bruheim