[Twisted-Python] Architecture question for multiple client connections (longish)

[Mark Johnston]

I'm working on a small Twisted program to take care of conditional access for 
a digital cable system.  All that really involves is receiving high-level 
update packets with a TCP server, storing the info into a database, and 
building and transmitting low-level update packets to the cable converters.  
Because of the way the tuners work, the update packets have to be sent (via 
TCP) to 10-15 different IPs, each one belonging to a different encoder.

I'm not really sure what the proper way to build a system like this is.  I've 
got the two Protocols written and working OK, and now I'm looking at how to 
propagate information from one to the other.  When I get an update packet on 
the high-level interface, I update the database, but I then want to have the 
low-level connections send an update to the encoders.

What I don't understand is how Factories come into the situation.  It looks, 
from the examples, that factories generally are instantiated for each 
connection [reactor.connectTCP(host, port, Factory())].  Supposing I 
instantiate the factories and save them:

for h in hosts:
    cf = MyClientFactory()
    reactor.connectTCP(h, 12345, cf)
    client_factories.append(cf)

Now, I get a high-level update on my server connection, which, after parsing, 
ends up running:

class ServerProtocol(Protocol):
    # . . .
    def activate_converter(self, converter):
        self.dbpool.runOperation("SQL etc.")
        # now send an update to each encoder for the converter

That's where I'm stuck.  The best I can do is:
        for f in self.factory.factories:
            f.last_proto.send(the_update)

This requires a special server factory that stores a list of the client 
protocol factories, and a special client factory that stores the last 
protocol instance it returned.  It seems like there must be a better way to 
accomplish this - perhaps without making a factory for each client protocol, 
which seems inelegant.

Thanks for any suggestions,
Mark