Opened 16 years ago

Closed 12 years ago

#1994 enhancement closed wontfix (wontfix)

ReconnectingClientFactory should wrap the protocol maker with a connectionMade that calls resetDelay for you

Reported by: ghazel Owned by: ghazel
Priority: normal Milestone:
Component: core Keywords:
Cc: Branch:


Why rely on a protocol to call resetDelay? I propose something like this (the implementation is sloppy, but you get the idea):

class SmartReconnectingClientFactory(ReconnectingClientFactory):

    def buildProtocol(self, *args, **kw):
        prot = ReconnectingClientFactory.buildProtocol(self, *args, **kw)
        old_connectionMade = prot.connectionMade
        def connectionMade(*a, **kw):
            return old_connectionMade(*a, **kw)
        prot.connectionMade = connectionMade
        return prot    

Change History (4)

comment:1 Changed 16 years ago by Jean-Paul Calderone

Perhaps ReconnectingClientFactory should be replaced with a WrappingFactory of some sort?

comment:2 Changed 16 years ago by naked

I assumed the resetDelay() call was supposed to be made only after all the connection setup work has been done, not simply because a TCP connection was established. Otherwise this would hammer the server if the server replies "not now" just after connecting.

A useful default would be that connectionMade causes resetDelay, but should be overridable, shouldn't it?

comment:3 Changed 15 years ago by Glyph

Owner: changed from Glyph to ghazel

comment:4 Changed 12 years ago by Jean-Paul Calderone

Resolution: wontfix
Status: newclosed

naked is right. Sometimes you have a server that accepts a connection and then very quickly drops it for whatever reason. It needs to be possible for resetDelay to be called only later, after some arbitrary point where the protocol has decided things have settled down.

Note: See TracTickets for help on using tickets.