[Twisted-Python] [Q] multi-process chat client and poller

Drew Smathers drew.smathers at gmail.com
Tue Jan 13 20:42:24 EST 2009


On Tue, Jan 13, 2009 at 4:11 PM, V S P <toreason at fastmail.fm> wrote
> Hi, thank you for the correction on how to use Ampula.
>
> Naming service serves
> really as a 'discovery' tool -- and then the participating
> components talk to each other.  When new component comes
> on online, it registers, and the Naming Service broadcasts
> the new updates to all the subscribed components.  It also
> can 'ping' the components to see if they are alive and if not
> it deletes an entry and broadcasts the updates to the remaning
> components.

It's sounds like what you want is erlang.  I'm only saying this
half-seriously.  Neither python or twisted have builtin mechanisms for
doing what you want.

> This way the message dispatchers (or components themselves) have
> almost up-to-date information about their peers on the network (the  is
> a delay controlled by ping interval).

Hmmm ... message dispatchers.  Are you building messaging middleware?
If so, you should probably stop now.  Here's something that already
works: http://www.rabbitmq.com

>
> The naming service data is sometimes stored on a file system
> (in case it crashes and needs to restart -- sort of like a
> 'session') with Python's serialization it has to be easy to do.
>
> But yes, a naming service while not a bottleneck --  can be
> a single point of failure in a distributed env, and that's why
> for 'fault safety' it is typically ran on fail-over hardware
> (although since it is not doing much, it rarely crashes :-))
>
> I certainly agree that using a naming service as a mechanism
> to get a 'context' of a remote process to invoke its methods
> (sort of get a Prospective Broker object from a naming service)
> every time a call is made -- would be inefficient and not correct.
>
> But if each component has the table of the registered components,
> then simply using that table to insanciate a Prospective Broker's
> RemoteReference for the needed remote component -- would be nice.
>
>
> Few people pointed out that a more generic service discovery
> systems exist and they use Dbus protocol (they are used to discover
> printers on the network, fileshares, etc) -- I have to study those.
>
> As far as XAMPP, I meant to ask: in twisted, does it run distributed
> on multiple machines (that is multiple xampp servers each on its own
> machine) -- if yes -- I thought it would have to have some kind of a
> naming service built in (I did not mean that XA (AMP) in the naming
> suggested that it is derived from Ampula :-)).  But may be it is
> single-machine/single-thread process only (I just did not know).
>

Still, what is XAMPP?  I think Valentino was assuming you mispelled
XMPP.  To partially answer this question though (excluding XAMPP as a
component), Twisted has protocols (AMP, PB, etc.) that make relatively
easy to build simple distributed systems (running on multiple
machines).  If you study hard and work hard you can also build more
complex distributed systems with grander scalability requirements.
Twisted does not magically cluster itself on multiple machines.

-Drew




More information about the Twisted-Python mailing list