[IPython-dev] Two frontends, one kernel

[Doug Blank]

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. 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?

Thanks so much... I feel I am getting close!

-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140502/a6e16606/attachment.html>