[Twisted-Python] Multicast XMLRPC
eprparadocs at gmail.com
Fri Aug 25 13:07:49 EDT 2006
Jean-Paul Calderone wrote:
> On Fri, 25 Aug 2006 12:05:50 -0400, "Chaz." <eprparadocs at gmail.com> wrote:
>> Samuel Reynolds wrote:
>>> At 2006-08-24 02:13 PM -0400, you wrote:
>>>> I have a thousand or more processors running in an application and
>>>> need to send out a request to each and every one of them.
>>> This is an incomplete statement of the problem.
>>> To get assistance you need to more fully
>>> state the problem you're trying to solve.
>>> What are you trying to accomplish?
>>> 1. Are you...
>>> a. sending data *to* each processor from a central server
>>> (e.g., configuration data)?
>>> b. retrieving data *from* each processor for
>>> display/processing at a central server
>>> (e.g., status information)?
>>> c. both?
>>> 2. How often do you need to send/receive the data?
>>> 3. How much latency is acceptable?
>>> 4. How much data loss is acceptable?
>> Since the title of the email is Multicast XML-RPC I would say I was
>> pretty specific. I need to send XML-RPC requests to thousands of
>> machines, something that can't be done using a connection oriented
>> protocol via TCP very efficiently.
> Multicast is a choice for a solution to a problem. So is "sending XML-RPC
> requests to thousands of machines". Neither are themselves descriptions
> of a problem; rather, they are descriptions of a solution.
> Sam is asking for more information about the problem you are trying to
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
I will state what I thought was obvious: I need to make "calls" to
thousands of machines to do something. I want to minimize the overhead
both of making the call and the machines sending back the responses.
On the invoking side I believe multicast or broadcast is the way to go
since I can send out one message and hit them all. On the response side
I need a low-overhead protocol.
TCP is pretty resource intensive so I need something else. I think a
reliable datagram service on top of some underlying transport is the way
to go (on top of multicast/broadcast/IP is what I am thinking about).
I think this describes the problem well.
More information about the Twisted-Python