I'm still working through your code example and trying to get a better grasp of what, exactly, you're trying to implement as far as client behavior is concerned. In the meantime, it sounds, on the surface, like you are trying to implement a form of the ReconnectingClientFactory: http://twistedmatrix.com/documents/current/api/twisted.internet.protocol.ReconnectingClientFactory.html .
Your client protocol must be factory aware and call the resetDelay method on the factory when a connection is made, but the factory will handle reconnecting and generating a new protocol instance. Is that similar to what you are trying to accomplish? Maybe see also http://twistedmatrix.com/documents/current/core/howto/clients.html#reconnection for a quick example of using the reconnecting factory. On Fri, May 6, 2016, 12:23 Daniel Sutcliffe <dan...@gmail.com> wrote: > Hello all, my first post here - only been using Twisted for about a > month and am also a relative newcomer to Python but have been coding > professionally for 20+ years. I was attracted to Twisted and Python > for a particular project purely because after research it seemed to be > the best tool for the job, and have actually been enjoying both Python > and Twisted much more than I ever thought I would. > > The project I am coding towards is creating a sensor data collection > gateway. First iteration needs are simply pulling data from ModBus TCP > slave PLCs and writing it to a MySQL database, but goals beyond that > are making the source of the data and its destination(s) very > flexible(pluggable). Therefore I am trying to create a good clean > architecture from the outset so as I iterate forwards I don't finish > up having to take too many steps backwards before heading forwards. > > I am using pymodbus to pull the data which works well for my devices, > has a twisted async API, and have created more than a few prototypes > that demonstrate all works as I expect. Where I am a bit stalled is > getting to grips with a good architecture that fulfills my needs - my > intention is that the application that meets my first goal will be a > twistd plugin. > > The new ClientService class seems like it will fit my needs very > closely but I am struggling with how to handle the reconnections... I > have been using the whenConnected() method to grab the Protocol for > the initial connection and then use a method of this to poll the > connected slave. When the connection is lost I get an errback from > this method's deferred which I use as a signal to abandon the Protocol > and call whenConnected() again... at this point I have an issue though > as the returned deferred immediately gives me a callback with the same > Protocol which has just lost its connection, and thus loop... > > Before I got on this mailing list I posted this Q to stackoverflow > with some example code: > http://stackoverflow.com/q/37061807/3448214 > but no solution or much attention there yet. > > As I say there, I realize I have probably just made a bad pattern > choice for how to use this API, but I have not been able to work out a > better choice which seems clean and fits my needs/understanding well. > I have tried deriving my own Protocol/Factory and handling the polling > there but this seems to get really messy once I start to add code to > get the collected data to a destination at that level, involving > giving the Protocol too much knowledge of how the data is to be > handled. > > Any advice, good patterns, or pointers to other projects which do > something similar is appreciated, > Cheers > /dan > -- > Daniel Sutcliffe <dan...@gmail.com> > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python >
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
