[Twisted-Python] Another tcp.Client question
Benjamin Bruheim
grolgh at online.no
Sun Sep 2 16:57:31 MDT 2001
> > No, it was just a test. Calling DTPLoseConnection actually would remove the
> > server since it would call Port.loseConnection, though trigging some unwanted
> > effects.
> Is the dtpPort supposed to accept more than one connection? I was under the
> impression that anywhere one would bind port 0 would be a place that one or
> only a few connections would be accepted.
yes, it shall accept one connection, and after the transfer is done, it shall close the connection (and in this way tell the user that the transfer is done). it shall let the tcp time-out, and that's why we change the port; less time is wasted between each new file. I am thinking of letting the user define a range of ports, and cycle through that instead of using port 0.
> > The port is created in FTP.createPassiveServer, and loseConnection is called
> > in DTP.finishGet (or DTP.finish, I don't think I've commited the namechange).
> You have committed it. Still: I see no loseConnection being called on a
> *Port*, only on a *Server*, which is a connection that got accepted from a
> port.
Isn't 'self.dtpPort = tcp.Port(0, self)' a Port? self.dtp.transport is self.dtpPort, and its method loseConnection is used. Besides, isn't Port the same as a server?
> That's as a result of seeing connectionLost, loseConnection is never
> necessarily called.
Figured :)
> > BTW, The point with my last reply was that I can't see that some of the code
> > changed are ever run, and that makes it hard to test ;)
> Yes, and my point is that, as far as I understand FTP, you *should* be
> exercising that code. I still don't understand why you're not.
Well, if I could. And how come nobody ever have run into that removeReader with an NameError or something?
// phed
More information about the Twisted-Python
mailing list