[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