[Twisted-Python] Multicast XMLRPC
eprparadocs at gmail.com
Thu Aug 24 14:13:09 EDT 2006
glyph at divmod.com wrote:
> On Thu, 24 Aug 2006 12:54:38 -0400, "Chaz." <eprparadocs at gmail.com> wrote:
>> Chaz. wrote:
>> It seems my one problem was that in the definition of my class...
> Those classes are not really meant to be used by subclassing.
>> That solved my immediate problem, though I did find out that XMLRPC
>> does in fact assume that you have a connection oriented protocol
>> underneath it. Now I will just have to fix that problem.
> How do you propose to "fix" that property of XMLRPC? It's not really a
> "problem", in that it's *defined* to use not only a connection, but an
> HTTP connection at that. From the XML-RPC specification: "An XML-RPC
> message is an HTTP-POST request."
> There is Jabber-RPC, which indicates how you might make an XMLRPC-*like*
> protocol over some other transport, but in your case that still requires
> a reliable multicast message delivery layer (a monumental task by itself).
> What is the application you are writing this for?
>> Also for those of you that said you can't do:
>> I would suggest you are wrong. In fact that is exactly how subclassing
>> works in Python. But that is for another time.
> You misunderstood. I assure you they were correct, but that isn't what
> they said. Simplified, here is what you did:
>>>> class A:
> ... def __init__(self):
> ... print self
>>>> class B:
> ... def __init__(self):
> ... A.__init__(self)
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "<stdin>", line 3, in __init__
> TypeError: unbound method __init__() must be called with A instance as
> first argument (got B instance instead)
> This is, in fact, illegal, and that is why you got the exception that
> you did.
> This is all moot, however, since you shouldn't use TCPServer with
> subclassing :).
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
First, I got the mistake I made. It was the standard "cut-and-paste"
problem. I cut code from one place, pasted it in another and forgot one
piece all together.
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. Obviously it is
impossible to send it out sequentially and it doesn't need to.
The model of communication I am working from is that most communications
are delivered and only once in a while do they fail (this is pretty true
of an un-congested ethernet-like network).
So my algorithm is as follows (and if someone sees something wrong
please let me know...a thousand pairs of eyes and brains is better than
one). Send out the RPC request via Multicast. Set some timeout (based on
the request type). Since I know the servers in the collection, when I
don't hear from one within the time out, resend the RPC request.
There is a problem with this approach - that is the semantics of the
call. Current RPC calls are EXACTLY ONCE semantics - it either works or
doesn't. In this there is an uncertainty - it might have worked and I
don't know about it (the response was lost for instance) or the server
itself failed and restarted. This means I can't every be guaranteed the
normal call semantics. It means it switches to AT LEAST ONCE semantics.
This means I have to be careful in how I code the server side.
Does anyone see another approach.
More information about the Twisted-Python