Brian,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
We have considered everything :).  The story of how we have arrived at<br>
0MQ is pretty interesting and worth recording.  We have had<br>
implementations based on XML-RPC, Twisted (numerous protocols, HTTP,<br>
PB, Foolscap) and raw sockets. I have played with earlier versions of<br>
RPyC as well.<br>
<br>
There are a couple of issue we keep running into with *every* solution<br>
we have tried (except for 0MQ):<br>
<br>
* The GIL kills.  Because IPython is designed to execute arbitrary<br>
user code, and our users often run wrapped C/C++ libraries, it is not<br>
uncommon for non-GIL releasing code to be run in IPython.  When this<br>
happens, any Python thread *completely stops*.  When you are building<br>
a robust distributed systems, you simply can&#39;t have this.  As far as I<br>
know all Python based networking and RPC libraries suffer from this<br>
same exact issue.  Note: it is not enough that the underlying socket<br>
send/recv happen with the GIL released.<br>
<br></blockquote><div>That sounds intriguing! How 0MQ is different in this regard, does it<br>maintain its own threads inside independent of GIL? <br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

* Performance. We need network protocols that have near ping latencies<br>
but can also easily handle many MB - GB sized messages at the same<br>
time.  Prior to 0MQ I have not seen a network protocols that can do<br>
both.  Our experiments with 0MQ have been shocking.  We see near ping<br>
latencies for small messages and can send massive messages without<br>
even thinking about it.  All of this is while CPU and memory usage is<br>
minimal.  </blockquote><div>It sounds you&#39;ve found a silver bullet :)<br>BTW I use twisted for client/server communication in my projects these days<br>and while I never had a need to transfer GB sized messages back and forth, <br>
I&#39;ve never had any issues with latencies either, except for the delays immanent<br>to some particular network.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
One of the difficulties that networking libraries in Python<br>
face (at least currently) is that they all use strings for network<br>
buffers.  The problem with this is that you end up copying them all<br>
over the place.  With Twisted, we have to go to incredible lengths to<br>
avoid this.  Is the situation different with RPyC?<br>
<br></blockquote><div>Yes string type is an old workhorse in python. I don&#39;t know internals of RPyC<br>but I suspect it uses strings extensively as well. What pyzmq uses instead of<br>strings?<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

* Messaging not RPC.  As we have developed a distributed architecture<br>
that is more and more complex, we have realized something quite<br>
significant: we are not really doing RPC, we are sending messages in<br>
various patterns and 0MQ encodes these patterns extremely well.<br>
Examples are request/reply and pub/sub, but other more complex<br>
messaging patterns are possible as well - and we need those. In my<br>
mind, the key difference between RPC is the presence of message queues<br>
in an architecture.  Multiprocessing has some of this actually, but I<br>
haven&#39;t looked at what they are doing underneath the hood.  I<br>
encourage you to look at the example Fernando described.  It really<br>
shows in significant ways that we are not doing RPC.<br>
<br></blockquote><div>Frankly I think the difference between messaging and RPC is mostly a<br>terminological one. A message queues presence really just means that the <br>system provides asynchronous services and many RPC frameworks<br>
provide that. (For some digression: In OO design world they even say <br>&quot;send a message to the object&quot; instead of &quot;call an object&#39;s method&quot; <br>sometimes. Wieird geeks :))<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

&gt; The reason is that IPython already has a lot of useful and exciting<br>
&gt; functionality and yet another RPC framework is somewhat too much. Plus,<br>
&gt; you don&#39;t have to think about these too low level details like communication<br>
&gt; protocols, serialization etc.<br>
<br>
0MQ is definitely not another RPC framework.  If you know that RPyC<br>
addresses some or all of these issue I have brought up above, i would<br>
seriously love to know.  One of these days, I will probably try to do<br>
some benchmarks that compare twisted, multiprocessing, RPyC and 0MQ<br>
for things like latency and throughput.  That would be quite<br>
interesting.<br>
<br></blockquote><div>Yes, 0MQ is not an RPC framework - it is just a low level protocol (albeit <br>probably a good one) that you will use to build your own RPC/RMI/messaging<br>system. Frankly I do not see 0MQ to be immune to all the issues you&#39;ve brought<br>
up above unless you&#39;ll drop python and code everything in C/C++. In my <br>experience latencies and and performance bottlenecks usually came from the<br>code that serves messages (i.e. server part) not the transport layer, unless you<br>
develop some high load server with thousands messages per second which is<br>not the case for IPython I believe. Or the network itself could be just slow, but <br>in this case no library could help unfortunately. But of course I can easily miss <br>
something obvious. <br><br>Please do not think that I&#39;m tying to bash the pyzmq idea, not at all! I think it is a <br>great idea for IPython and it will be a real fun to implement. I&#39;m just trying to <br>understand what is so different in IPython that any other RPC/RMI/messaging <br>
framework can&#39;t fit? RPyC along side with Pyro was just the first one that came <br>to mind when I read Fernando&#39;s post but there are a lot of them, see for example<br>python&#39;s wiki for a list: <a href="http://wiki.python.org/moin/ParallelProcessing">http://wiki.python.org/moin/ParallelProcessing</a>.<br>
I personally have successfully used another toolkit not mentioned on the above <br>page  - <a href="http://www.spread.org">http://www.spread.org</a> - it is a group communication toolkit that provides<br>guarantied message delivery and so called virtual synchrony.<br>
<br>I think that when the first excitement ends and you will start to develop this new<br>interface, you will end up implementing all this functionality that other RPC <br>frameworks have or the most of it, so it would be useful to at least check them <br>
before implementation. <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Another important part of 0MQ is that is runs over protocols other<br>
than tcp and interconnects like infiniband.  The performance on<br>
infiniband is quite impressive.<br>
<br></blockquote><div>Cool! Any Idea how to utilize it in python/IPython?<br><br>Regards,<br></div></div>-- <br>Mikhail Terekhov<br>