Something like asynchronous XML-RPC possible?

["Martin v. Löwis"]

Will Stuyvesant wrote:
> Well I just do not understand how to use the UDPRequestHandler (or
> something like that) and HTTPServer(protocol = "UDP") and registering
> an instance object with it so its "methods" act like event handlers
> (caller not blocking and no return value send back to caller).  

I see. I believe you cannot readily use the HTTPServer class, since it 
assumes connection-oriented communication - it needs to send a reply, 
and it assumes that it can send the reply back on the same file 
descriptor/socket handle from which it got the request, just by 
performing an un-addressed send on it (I believe it actually performs 
makefile, then .write).

You should also explain what "HTTP over UDP" means to you: how is a HTTP 
request transmitted via UDP?

For TCP, it is often the case that a single HTTP request is transmitted 
in multiple IP packets. For UDP, this would be bad, since you cannot 
rely that the packets are received in the same order in which they are sent.

So you might have to sent the entire HTTP request in a single packet. 
This, of course, limits the request size to a single packet, and may 
fail silently if the packet size exceeds the maximum segment size of the 
connection (which you cannot determine, since you use connection-less 
communication).

In any case, I recommend that you just use the various Request objects, 
and simulate streams by putting the data into StringIO classes. Then, 
you assemble and disassemble entire requests in such a StringIO class, 
and transmit them in single send/recvfrom calls.

> I did
> not find much examples in the docs, and the examples I found were all
> about TCP.  

Not surprisingly so, since UDP is so much more painful for real world 
applications that nobody uses it unless the other end already mandates 
it. You must have very large resources, in terms of man-power, if you 
want to use UDP.

 > There is one example called "Heartbeat" that does UDP but
> I would have to rewrite the "requesthandler" and to provide a
> registering mechanism like SimpleXMLRPCServer has.  Uh oh.  This just
> gets over my head.  Am I making sense here? :)

Not really. I still recommend you start with the client, and leave the 
server for later.

For the server side, I recommend that you ignore all these processing 
layers, and try to use the plain socket API first - to get a working 
peer. For the moment, something that merely prints all packets it 
receives might be sufficient to demonstrate that the client works. If 
you have that working, and you still don't see how to proceed, please 
ask again.

Regards,
Martin