Something like asynchronous XML-RPC possible?
"Martin v. Löwis"
martin at v.loewis.de
Fri Jan 24 16:16:24 CET 2003
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
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
More information about the Python-list