[IPython-dev] Two frontends, one kernel

Min RK benjaminrk at gmail.com
Fri May 2 18:25:17 EDT 2014



> On May 2, 2014, at 14:31, Doug Blank <doug.blank at gmail.com> wrote:
> 
>> On Fri, May 2, 2014 at 1:04 PM, MinRK <benjaminrk at gmail.com> wrote:
>>> On Fri, May 2, 2014 at 9:04 AM, Doug Blank <doug.blank at gmail.com> wrote:
>>> 
>>>> On Thu, May 1, 2014 at 5:35 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>> ROUTER sockets use an IDENTITY prefix to determine who the recipient should be.
>>> 
>>> Ok, I think I understand, but still not working. Here is some wording that (if correct) could be inserted in an expanded discussion of the wire protocol (which doesn't yet mention socket type):
>> 
>>> http://ipython.org/ipython-doc/dev/development/messaging.html#the-wire-protocol
>>> 
>>> """
>>> If you only want to implement basic functionality (one frontend per kernel, no parallel or cluster support) then using DEALER instead of ROUTER is fine, and a good place to start because you don't need the complexity of the routing protocol. You can simply leave out the routing prefixes before the <IDS|MSG> delimiter in the wire protocol.
>>> 
>>> If you do want more than the basic functionality (such as allowing two frontends to a kernel) then you must use the ROUTER socket type, and must have the correct routing prefixes.
>>> """
>> 
>> I would not add this. I would consider it purely an accident that any kernel with DEALER sockets sometimes appears to work, and no kernel should ever use DEALER sockets on the kernel.
>> 
> Just to be clear, using DEALER always works without any routing identifiers, with all of the frontends (only one at a time, or course). IPython may not have been design to work this way, may have security issues, and may not work in the future. But with IPython 1, and 2, it works.

Also to be clear: this will stop being true in master next week, which is why I don't think it's worth mentioning that DEALER sockets sort of work sometimes, because it is always the wrong thing to use.

> But now to my question:
>  
>> I think suggesting that DEALER sockets might work in simple cases would only increase the likelihood that new kernels use dealer sockets, when none should.
>> 
>> The addition of a kernel_info request at startup, which is about to go into IPython master, will mean that no kernel using DEALER sockets will work in any frontend, because there will be a minimum of two client sockets connected to the kernel’s shell channel.
>> 
>>> 
>>> The problem is that I haven't gotten the routing to work, and it seems like it deserves some documentation. For example, watching the IPython kernel, I appear to see the following kinds of routing:
>>> 
>>> message type: "kernel_info_reply", routing appears to be "SESSION_ID":
>>> 
>>> 
>>> message type: "status", routing appears to be "kernel.KERNEL_ID.status":
>>> 
>>> 
>>> message type: "execute_repl", routing is "execute_reply", raw data (end of message) is list of session ids:
>>> 
>>> 
>>> Am I reading this correctly? If so, then many kernel developers may stop at basic communication and use DEALER (which is fine, I guess). For those of us you want to implement the full spec (with the expectation of having parallel engines working), each of these cases will need to be dealt with, right?
>> 
>> I suppose I should add a bit of a zmq primer to the message spec. The relevant bits:
>> 
>> ROUTER sockets use IDENTITIES to pick the peer to send messages to. This is the part of the message preceding the ‘‘ delimiter. A ROUTER must send replies with the same routing prefix as the requests it receives.
>> 
> That is an important bit of info! The IPython section on the wire protocol is very misleading in this routing section.
>> PUB sockets are different. PUB sockets use only the first message part as a TOPIC, on which sub sockets can filter. In IPython, this is generally ignored, but the message spec describes what IPython does with pub topics. The PUB topic should not be the routing prefix used by the ROUTER socket.
> What is the "first message part"?
> 
> Rather than a primer on zmq, I'd rather see something very specific with respect to IPython. What does the request look like? What should the PUB response look like? What would a ROUTER response look like?
> 
> Is it true that all kernel sends are in response to a request, except for the very first "starting" status message? In that case, it creates a routing identity from scratch?

Adding an example request/iopub/reply cycle in the wire format is a good idea. I will try to draft one this weekend. The general principal: one request has one reply. the routing identity is relevant only to that one reply, and the reply's routing prefix should be identical to the request's. Side effect messages on IOPub do not use routing identities. But they do have a slightly analogous behavior called a subscription topic. This value should not be influenced by the routing prefix, and in practice has no effect because frontends subscribe to all topics (this last statement is already in the msg spec doc).

-MinRK

> 
> Thanks so much... I feel I am getting close!
> 
> -Doug 
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140502/62f1cb64/attachment.html>


More information about the IPython-dev mailing list