[Twisted-Python] Server with several outgoing connections

[Seun Osewa]

You might also want to consider the design of your application in case
it's not the best way of solving the problem using Twisted (for
example if all the nodes run on the same computer ....)


On Fri, 05 Nov 2004 10:39:09 -0600, Eric Mangold <teratorn at world-net.net> wrote:
> 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
> 
> 
> 
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>