On 26 Sep 2000 12:50:00 -0500, Shane Hathaway wrote:
Here's what Sam Rushing told me regarding this issue.
Shane Hathaway writes:
I hear that you have found a way to get Medusa to use the correct port in active mode FTP. This could be a great benefit to the Zope community. Anything you have (diffs, modified files, or any kind of info) on the subject would be very much appreciated.
(Sam writes:) [...]
See the 'bind_local_minus_one' variable of the ftp_channel class. This should be checked into the medusa cvs, but I'll attach a copy as well.
/* According to one expert, the very nature of the FTP protocol, * and it's multiple data-connections creates problems with * "rapid-fire" connections (transfering lots of files) causing * an eventual "Address already in use" error. As a result, this * nasty kludge retries ten times (once per second) if the * port being bound to is INPORT_ANY) */
This does not occur just during 'rapid-fire connections'. AFAI can tell, it *always* fails to bind to port 20 in this case. So I don't think this is the problem. Back to my question - Why would a port 20 bind() lock up the medusa process when absolutely no other transaction is transpiring on the server? Under what condidtions woudla bind() simply stop? - not fail, just fail to return from the bind() call?
In other words, it's just bound to fail. A forking server can afford this sort of persistence, but in medusa I think it'd be overkill; I'd have to set up event timers, an object to maintain the retry state, etc.... [this alone it might add 50% to the size of ftp_server.py] ---
I'd have to agree with Sam, it's just not worth the effort.
So you are saying ZServer just isn't ever going to support Active ftp clients in the correct port-1 manner? If so, you might want to put a LARGE BANNER disclaimer about this matter as this makes ZServer unusable from most ftp clients that try to access it from behind standard a firewall. (And yes, on checking, it appears that the only OSes we could locate that come with a passive ftp client by default are the BSD's).