[Twisted-Python] Need help for structured application development

Johann Borck johann.borck at densedata.com
Thu Feb 18 23:45:28 EST 2010


Einar S. Idsø wrote:
> On Thu, Feb 18, 2010 at 11:36 AM, Johann Borck
> <johann.borck at densedata.com> wrote:
>   
>> Einar S. Idsø wrote:
>>     
>>> [...]  I guess I need a factory that launches server checker
>>> objects not as a result of a TCP/UDP connection, but as a result of
>>> new servers being detected.
>>>       
>> How does this detection work? Are those servers based on twisted? Also,
>> do you control them (start/stop/configuration), do you have access to
>> the machines they're on, or are you detecting them over network only?
>>     
>
> Johann: Thanks for your response. I do control these services myself,
> and they run on our own hosts, but they are created and spawned via an
> external web interface which also has a Soap API. I do not plan on
> starting/stopping them via this application I'm developing. I just
> need to get the list of servers and start polling them. I get the list
> by calling the Soap webservice. It simply outputs a list of servers,
> and it is my job to query each and every one at specific intervals for
> status.
>
> I was thinking I would have the Soap-query run as a timed function
> every few minutes, and compare the new list with the old to work out
> any new/removed servers. Whenever a new server is identified, I will
> spawn a new object to deal with it, including, but not limited to,
> polling at given intervals. What kind of object should this be? A
> ClientFactory? Another kind of object that is already defined
> somewhere in Twisted? A completely custom object, built from scratch?
> I am leaning towards ClientFactory, but I am definitely not certain.
>
>   
I see. So if I get these requirements right you have 5-10 services with 
1-30 instances of each, with following properties relevant to the task 
at hand:

1. those pollable by your existing program.
2. those incompatible with your existing program.
3. those that do not stream additional data.
4. those that do stream additional data.

since sets  (1 and 2) and (3 and 4) are distinct, the combinations 
(1,3),(1,4),(2,3),(2,4) are possible.

(1,3) the easy one, obviously you just need an object that polls the 
service using your program in intervals specific to the service.
(1,4) Question: will the data you're interested in be collected by your 
existing program or by twisted? In the former case, it's basically the 
same as (1,3), in the latter you'll have to implement a protocol.
(2,3) for these you'll need to implement a protocol class.
(2,4) here you'll have to implement one or two protocols, depending on 
how the service is implemented.

Is the above about correct? I think it would be a good idea to have an 
object OB that keeps references to all objects that gather data from the 
services, grouped by the type of service they're responsible for 
(defaultdict(list or dict) comes to mind). And then you'll probably 
either want factories that take care of handing newly created protocol 
instances over to OB or some instances (one or two per service in sets 
(2,3,4) ) of a multipurpose factory that can be initialized with the 
respective protocol and the information how to pass the created protocol 
over to OB, maybe  just a simple method that is able to distinguish the 
protocols by the interfaces they implement.

One pitfall might be your polling program in case you're using 
t.i.u.getProcessOutput. It (t.i.u...) provides an asynchronous 
interface, so the worst that can happen is a stray process that doesn't 
return, but you still might want to consider implementing a 
ProcessProtocol 
(http://twistedmatrix.com/documents/current/core/howto/process.html) 
with a reasonable timeout, to be able to kill the spawned process in 
case it doesn't terminate. Thinking about it, it's the better solution 
anyway, because process protocols are just another type of protocol in 
twisted, and can be integrated consistently with the rest of your app.

Another utility you might want is t.i.task.LoopingCall, for obvious 
reasons. Given your requirements something along these lines would be my 
approach, although I'd probably reimplement the polling thingy in 
twisted if it's not too complex :)

hope that makes sense,
Johann




More information about the Twisted-Python mailing list