[Twisted-Python] ftpclient connection lost callback
I am writing a simple ftp client which I am trying to dispose of. Right now I send a quit command: (the ftp_client reference is a FTPClient built with a ClientCreator) deferred = ftp_client.quit() And I register a callback: def quitSent(response): print "quit acknowledged...connected?", ftp_client.transport.connected deferred.addCallback(quitSent) If I invoke the above the connection is printed as connected. However if I schedule a callback to check the status later: def status(): print "quit acknowledged...connected?", ftp_client.transport.connected reactor.callLater(1, self.status) If I schedule a callback for a second later the transport is not connected. I've searched quite a bit but I cannot determine a way to register a callback for when the TCP transport is actually disconnected. Can anyone offer some insight? I'd like to know explicitly when the client is closed. Thanks, Peter
On 05:49 pm, peter@peterryan.net wrote:
There is no documented `connected` attribute of transports. So who knows what this is telling you. :) However, the way you learn when a protocol's transport has disconnected is to implement the `connectionLost` method on the protocol. It is called when the transport disconnects. Jean-Paul
Thanks. So is the idiomatic approach for this with something like the FTPClient to subclass it and override connectionLost? FTPClientBasic clears up queued commands when this happens (which I assume I still want it to do). To me it seems a little overbearing to have to subclass the ftpclient just to get a tcp connection lost event (which seem like an event most users would be interested in). On Thu, Sep 5, 2013 at 1:35 PM, <exarkun@twistedmatrix.com> wrote:
On 06:48 pm, peter@peterryan.net wrote:
Is it idiomatic? I don't know. It accomplishes your goal. If you like, propose a better API (file a ticket, attach a patch, etc: http://twistedmatrix.com/trac/wiki/ContributingToTwistedLabs#CodeContributio... ) Jean-Paul
On 05:49 pm, peter@peterryan.net wrote:
There is no documented `connected` attribute of transports. So who knows what this is telling you. :) However, the way you learn when a protocol's transport has disconnected is to implement the `connectionLost` method on the protocol. It is called when the transport disconnects. Jean-Paul
Thanks. So is the idiomatic approach for this with something like the FTPClient to subclass it and override connectionLost? FTPClientBasic clears up queued commands when this happens (which I assume I still want it to do). To me it seems a little overbearing to have to subclass the ftpclient just to get a tcp connection lost event (which seem like an event most users would be interested in). On Thu, Sep 5, 2013 at 1:35 PM, <exarkun@twistedmatrix.com> wrote:
On 06:48 pm, peter@peterryan.net wrote:
Is it idiomatic? I don't know. It accomplishes your goal. If you like, propose a better API (file a ticket, attach a patch, etc: http://twistedmatrix.com/trac/wiki/ContributingToTwistedLabs#CodeContributio... ) Jean-Paul
participants (2)
-
exarkun＠twistedmatrix.com -
Peter Ryan