[Twisted-Python] Multicast XMLRPC

Chaz. 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:
>>
>> internet.TCPServer.__init__(self,...)
>>
>> 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)
> ...
>>>> B()
> 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
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
> 

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.

Chaz






More information about the Twisted-Python mailing list