[Twisted-Python] reconnecting from the client
Hello, in my simple client I need a mechanism for reconnecting to the server: 1. If the server is not responding at the momment, the client should keep trying to connect 2. If the connection once become active and the server is restarted, the client should reconnect 3. If the connection is active and no data can be transmited / received for X seconds (link down, router down), the client should try to reconnect as in the case (1.) (as if the client has never been connected) It should react in less then 10 seconds. Unfortunately I can not detect the situation (3.). If I unplug the ethernet while connected, none of my methods is called (ever). I couldn't find anything like this in the documentation or in the examples. Here is my testfile: -------------- from twisted.internet.protocol import Protocol, ReconnectingClientFactory from twisted.internet import reactor class Echo(Protocol): def dataReceived(self, data): print data def connectionLost(self, reason): print 'connection lost', reason def connectionMade(self): reactor.callLater(1.0, self.ping) print 'connection made' def ping(self, *args): self.transport.write('test') reactor.callLater(1.0, self.ping) class EchoClientFactory(ReconnectingClientFactory): maxDelay = 3 def startedConnecting(self, connector): print 'started to connect' def buildProtocol(self, addr): print 'connected' self.resetDelay() return Echo() def clientConnectionLost(self, connector, reason): print 'lost connection', reason ReconnectingClientFactory.clientConnectionLost(self, connector, reason) def clientConnectionFailed(self, connector, reason): print 'connection failed', reason ReconnectingClientFactory.clientConnectionFailed(self, connector, reason) reactor.connectTCP('10.10.2.77', 23, EchoClientFactory()) reactor.run() -------------- regards, Zoran Bosnjak
Bosnjak Zoran ITWEP <Bosnjak@iskratel.si> wrote:
This isn't a Twisted thing, it's a TCP thing. When you unplug your ethernet cable, packets start to silently fall on the floor. It's only after the TCP layer times out without seeing expected ACK packets that it'll consider the connection lost. Up until that point, it just thinks the connection has high latency that's getting higher all the time. The TCP timeout is often set at several minutes. If you want a ten second response to lost packets, you should implement some kind of ping and/or timeout mechanism yourself, on top of TCP. A router busted in the appropriate way will send ICMP host unreachable or network unreachable messages, and the TCP layer will be able to immediately detect a connection broken in this way. Your operating system may provide a way of tuning TCP connection parameters, in which case you may be able to get the TCP timeout down to ten seconds. Expect lots of broken connections. I'm not sure if that would violate the various TCP RFCs either. -- Sam "Eddie" Couter | mailto:sam@couter.dropbear.id.au Debian Developer | mailto:eddie@debian.org | jabber:sam@teknohaus.dyndns.org OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
Bosnjak Zoran ITWEP <Bosnjak@iskratel.si> wrote:
This isn't a Twisted thing, it's a TCP thing. When you unplug your ethernet cable, packets start to silently fall on the floor. It's only after the TCP layer times out without seeing expected ACK packets that it'll consider the connection lost. Up until that point, it just thinks the connection has high latency that's getting higher all the time. The TCP timeout is often set at several minutes. If you want a ten second response to lost packets, you should implement some kind of ping and/or timeout mechanism yourself, on top of TCP. A router busted in the appropriate way will send ICMP host unreachable or network unreachable messages, and the TCP layer will be able to immediately detect a connection broken in this way. Your operating system may provide a way of tuning TCP connection parameters, in which case you may be able to get the TCP timeout down to ten seconds. Expect lots of broken connections. I'm not sure if that would violate the various TCP RFCs either. -- Sam "Eddie" Couter | mailto:sam@couter.dropbear.id.au Debian Developer | mailto:eddie@debian.org | jabber:sam@teknohaus.dyndns.org OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
participants (2)
-
Bosnjak Zoran ITWEP -
Sam Couter