[Twisted-Python] Server with several outgoing connections

Eric Mangold teratorn at world-net.net
Fri Nov 5 11:39:09 EST 2004


On Thu, 4 Nov 2004 10:37:53 +0100, Roland Hedberg
<roland.hedberg at adm.umu.se> wrote:

> Hi!

Hello.

>
> I'm new to Twisted and I have tried to read and understand the intricate  
> sides of it.
> And have found as so many other that the learning curve pretty steep,  
> especially I guess if one comes from being a C programmer :-)
>
> Anyway, this is my problem:
>
> I'm building a system that consists of a number of nodes, each node  
> acting as a receiver and transmitter of messages. The protocol used  
> between the nodes might be a message passing system like xmpp or  
> something else. The number of nodes are dynamic and might change at any  
> time. Plus there is no way by which you can know when the system is  
> started how many nodes there will be. Also nodes might receive messages  
> from any number of nodes and be expected to transmit the messages to  
> several nodes.
>
> Writing the 'server' part of a node is easy, plenty of examples of that  
> exists on the net.
>
> Writing the 'client' side is not so easy and here I guess my C legacy is  
> hampering me.
>
> So I'd like someone to give me, or point me, to an example on how to  
> dynamically create new connections to receivers.

I don't see the need for anything special. The reactor.connectTCP function
is probably what you want.

> I first though these connections should be shortlived that is 'open the  
> connection, send the message, receive the ACK and close the connection'  
> but now I think it might be wiser to keep the connections as long as  
> possible. That is, until that receiver disappears.

Just call transport.loseConnection() when you want it to go away.

>
> Another side of this is that the influx of messages might be higher than  
> the possible output, that is each node has to keep queues for messages  
> not yet sent and messages sent but not ack'ed.
> It might also happen that recivers of messages are not accessible in  
> which case the message has to be queue until the receiver pops up again.  
> The system is not allowed to drop messages.
> Note, that each incomming message might have several receivers, so one  
> incomming message might end up in the sendqueue of several receivers.

...

>
> And here in lies one of the problems, I guess I have to keep a  
> 'centrally' managed queue, that should then be notified on the change of  
> status of a message on route to a recevier. How should I implement this ?

*shrug*, depends on the application. Do you want central management?
Do you really need it?


You really need to ask some more specific questions before anyone can give
you good answers.

-Eric




More information about the Twisted-Python mailing list