SimpleXMLRPCServer

[Yannick Turgeon]

I plan to use XML-RPC to communicate between my python server and VB client.
I just called a simple registered function (lambda x,y: x+y) and it worked.
But I'm new to XML-RPC and I'm now wondering why this class is called
"Simple". What are its limitations? I want to know if I can count on it for
my project or if I would need a not-so-simple XML-RPC server.

Yannick

 

[Istvan Albert]

"Simple". What are its limitations?

No limitations whatsoever ... it is "Simple" to use

:-0

Istvan.

 

[Jeremy Jones]

No limitations whatsoever ... it is "Simple" to use

:-0

Istvan.

Simple indeed. I don't know for sure the reasons for naming it
"Simple". But it may have to do with the fact that the out-of-the-box
SimpleXMLRPCServer will only handle one request at a time: a request
comes in, the server accepts that request, blocking until the method
call returns, and the response is sent back to the client. It does not
spawn a thread per request. It does not "select" among multiple
requests. It will not create a thread pool for you. If you want that
added functionality, you can write a little custom code to get it to
spawn a thread per request. A little more code to only spawn n number
of threads. A little more code still to create a thread pool. And if
you want a server that "select"s among multiple requests, I'm not 100%
sure, but I bet Twisted has one of those.

But I've got a good bit of confidence in the "SimpleXMLRPCServer." I've
written a small modification to spawn a thread per request and am about
to write a test harness to pound my underlying library to pieces through
the slightly modified SimpleXMLRPCServer. I'm hopeful for good results
- at least in robustness if not performance.

HTH,

Jeremy

 

[PhysicsGenius]

Simple indeed. I don't know for sure the reasons for naming it
"Simple". But it may have to do with the fact that the out-of-the-box
SimpleXMLRPCServer will only handle one request at a time: a request
comes in, the server accepts that request, blocking until the method
call returns, and the response is sent back to the client. It does not
spawn a thread per request. It does not "select" among multiple
requests. It will not create a thread pool for you. If you want that
added functionality, you can write a little custom code to get it to
spawn a thread per request. A little more code to only spawn n number
of threads. A little more code still to create a thread pool. And if
you want a server that "select"s among multiple requests, I'm not 100%
sure, but I bet Twisted has one of those.

I have a non-threaded, select()ing SimpleXML-RPC
server. I have stressed it yet, but I have
verified that the concept works.

 

[Jeremy Jones]

I have a non-threaded, select()ing SimpleXML-RPC server. I have
stressed it yet, but I have verified that the concept works.

Is this something that you wrote, or are you using Twisted? If it's
something you wrote, I'd love to see the code for it.

Jeremy

 

[Rembrandt Q Einstein]

Is this something that you wrote, or are you using Twisted? If it's
something you wrote, I'd love to see the code for it.

Jeremy

Maybe "server" is too grand a term. This is running inside an actual
server, but this is really just a snippet of code for doing select() on
an XML-RPC server socket.

server = XMLRPCServer.XMLRPCServer((ipAddr, port), logRequests=False)
while(True):
inputs, outputs, exceptions =
select.select([server.fileno(),],[], [],
configOptions['tick'])
if inputs:
server.handle_request()

 

[Brian Quinlan]

Simple indeed. I don't know for sure the reasons for naming it
"Simple". But it may have to do with the fact that the out-of-the-box
SimpleXMLRPCServer will only handle one request at a time: a request
comes in, the server accepts that request, blocking until the method
call returns, and the response is sent back to the client. It does not
spawn a thread per request.

The name SimpleXMLRPCServer is in line with SimpleHTTPServer: a simple
serial request handling server that can be subclassed to provide
additional functionality. I also chose SimpleXMLRPCServer because I
reasoned that some day someone would want to write a server using a
different technique and SimpleXMLRPCServer could be refactored into
BaseXMLRPCServer and SimpleXMLRPCServer without breaking anything. That
would allow NewXMLRPCServer to leverage the new BaseXMLRPCServer.

Cheers,
Brian

 

[Yannick Turgeon]

Simple indeed. I don't know for sure the reasons for naming it
"Simple". But it may have to do with the fact that the out-of-the-box
SimpleXMLRPCServer will only handle one request at a time

Oh! Ok, that's good. Thanks.

Yannick

 

[Skip Montanaro]

Jeremy> ... the out-of-the-box SimpleXMLRPCServer will only handle one
Jeremy> request at a time... It does not spawn a thread per request.

Nor should it. Enabling threading in an application should be an active
step taken by the programmer, not a passive step taken as a side effect of
using a particular class that doesn't mention threading. The simplest part
of making a server threaded is mixing in SocketServer.ThreadingMixin. Far
more work needs to be done to make it robust.

Now, should the SimpleXMLRPCServer module provide a threaded version?
Perhaps. The default should be non-threaded however.

Skip

 

[Jeremy Jones]

Jeremy> ... the out-of-the-box SimpleXMLRPCServer will only handle one
Jeremy> request at a time... It does not spawn a thread per request.

Nor should it. Enabling threading in an application should be an active
step taken by the programmer, not a passive step taken as a side effect of
using a particular class that doesn't mention threading. The simplest part
of making a server threaded is mixing in SocketServer.ThreadingMixin. Far
more work needs to be done to make it robust.

Now, should the SimpleXMLRPCServer module provide a threaded version?
Perhaps. The default should be non-threaded however.

Skip

I don't disagree at all. The example that I got from somewhere that I
still use as my base template to create a threaded XMLRPCServer is all
of 6 lines of code. It's trivial. And that could probably be trimmed
down a bit.


Jeremy