[IPython-dev] Notebook doesn't respond to external kernel's kernel_info_request properly

MinRK benjaminrk at gmail.com
Wed Feb 4 13:15:42 EST 2015


On Wed, Feb 4, 2015 at 9:13 AM, Doug Blank <doug.blank at gmail.com> wrote:


>
> On Wed, Feb 4, 2015 at 12:00 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>> On Wed, Feb 4, 2015 at 3:23 AM, Doug Blank <doug.blank at gmail.com> wrote:
>>
>> On Tue, Feb 3, 2015 at 11:58 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>
>>>> I've looked through the code and I don't see any of the likely
>>>> culprits. It is definitely the identities that determine the destination of
>>>> a message, so that's where I would start to debug. I don't have a C# dev
>>>> environment, so I can't dig much deeper myself.
>>>>
>>>
>>> Thanks for looking at this. Where in the IPython code do identities get
>>> decoded and then routed? Maybe I can see there what the notebook is
>>> actually receiving from the kernel and what it actually should be.
>>>
>> They don’t get decoded at all, but they are gathered from the message
>> content in Session.feed_identities
>> <https://github.com/ipython/ipython/blob/master/IPython/kernel/zmq/session.py#L732>,
>> and then used unmodified to route the reply.
>>
>> I think I might know what’s going on, though. I see UTF8 used on every
>> send/recv, but identities are not UTF8, they are binary blobs (uint32 by
>> default). So if it’s coercing those to UTF8, the value of the identity will
>> be lost in encoding errors.
>>
> Ok, thanks... that gives me some things to try. Perhaps if I just change
> the way that the sockets read/write it may work?
>
I’m not familiar with C# or the API for the C# zmq bindings, but you will
want to treat the identity prefix as binary blobs, not text.


> This could be why it works in some places and not others - we set a manual
>> identity on *most* sockets, which we use to associate the stdin channel
>> with a given request. These happen to be ASCII, but could jut as easily be
>> random binary values. We don’t set an identity on the socket used for the
>> kernel_info_request that starts off the notebook connection, though.
>>
> Hmmm... but I am getting a 5 to 8 byte identity string on the
> kernel_info_request... what does that imply? It is a ZMQ identity? It could
> be ignored? Or, I must respect it, and send it back (in proper form) with
> the response?
>
The first N frames of the message (typically 1) are the identity prefix.
These should be treated as opaque binary blobs. They will be followed by
the delimiter (should really have been an empty string, but I never removed
my toy delimiter before it was too late). The reply must be sent with the
exact same identity prefix in order to arrive at the correct destination.A
reply should always be identical to its request, up to and including the
delimiter frame. This is how ZeroMQ decides where messages should be routed.

In IPython, the identity prefix is either 1 or 2 frames, but it can
technically 0-many (1-many for ROUTER sockets). They should be treated as
opaque bytestrings, and never interpreted as text, even though some subset
of them may happen to be valid ASCII. You don’t have to do anything with
these frames other than collect them until you hit the delimiter, and make
sure to send them back unmodified as the prefix for the reply.

-MinRK


> -Doug
>
>
>
>> -MinRK
>>
>>
>>> -Doug
>>>
>>>
>>>
>>>>
>>>> -MinRK
>>>>
>>>> On Tue, Feb 3, 2015 at 8:55 AM, Doug Blank <doug.blank at gmail.com>
>>>> wrote:
>>>>
>>>>> IPython devs,
>>>>>
>>>>> Having a problem trying to get an external C# kernel to work with the
>>>>> notebook. Everything appears to work fine, except for the
>>>>> kernel_info_request. "kernel_info_request" seems to work fine with the
>>>>> console, but not from the notebook.
>>>>>
>>>>> Can you think of a reason that the kernel_info_reply wouldn't get back
>>>>> to the right receiver in the notebook? Could it be the identities? Do they
>>>>> play a role in this?
>>>>>
>>>>> The code is here:
>>>>>
>>>>> https://github.com/dsblank/simple_kernel/blob/master/SimpleKernel.cs
>>>>>
>>>>> Any ideas appreciated... I've tried to follow why it wouldn't get
>>>>> routed back to the handler, but haven't found the problem yet.
>>>>>
>>>>> -Doug
>>>>>
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>>>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
> _______________________________________________
> 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/20150204/f5a6eced/attachment.html>


More information about the IPython-dev mailing list