[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:
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.
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
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
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,
On 05:49 pm, peter@peterryan.net wrote:
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.
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
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
______________________________**_________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.**com
http://twistedmatrix.com/cgi-**bin/mailman/listinfo/twisted-**pythonhttp://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On 06:48 pm, peter@peterryan.net wrote:
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).
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
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,
wrote: On 05:49 pm, peter@peterryan.net wrote:
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.
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
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
______________________________**_________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.**com
http://twistedmatrix.com/cgi-**bin/mailman/listinfo/twisted-**python<http://twistedmatrix.com /cgi-bin/mailman/listinfo/twisted-python>
participants (2)
-
exarkun@twistedmatrix.com
-
Peter Ryan