[IPython-dev] "Unsigned Message" error in a forking kernel manager

[Jason Grout]

On 5/29/12 8:19 PM, MinRK wrote:
> That should be unnecessary, because you can just pass a config object:

Great!  Thank you!  I feel like I spend a lot of time poking around in 
the code because I'm not familiar with the mindset of the code (for 
example, thanks for the advice about KernelManager vs. 
BlockingKernelManager).

One thing that I'm still not understanding deeply enough is how Traits 
and the ipython config system really works, so I appreciate your 
comments and modifications there too.


>
> cfg = Config()
> cfg.Session.key = foo
>
> embed_kernel(config=cfg)
>
> There should be nothing at all that you cannot specify with the current
> call as it is.

Thanks.  I'll be thinking of how I can do things with Config objects in 
the future.


>
> But that's all beside the point, because the normal way to communicate
> connections to the kernel is through a *file* (App.connection_file
> configurable).  I know it may seem odd to use files when you are using
> fork, but this will still be required if you want to start other
> frontends against that kernel.

In our specific case, we plan to fork hundreds of these instances as 
very short-lived computation engines (it's a rewrite of the sage cell 
server).  We don't see a use-case for other clients connecting to the 
engine (indeed, the engine is on a separate server that has no 
connection to the user except through our designated channel, and we 
want to keep it that way for security).  Another reason to not write a 
file to disk containing the security key is to prevent two different 
forking engines (but from the same user) from accessing the same secret 
key.  We'll have two completely different web users launching two 
different kernels (same user account) to do computations.  It would be 
bad if one user can trivially read a file to see how to mess up the 
other kernel.  If we generate a random key and pass it on to the forked 
kernel in memory, it makes it much harder for the second user to send 
messages to the first kernel.


>
> Here is a fork of your script that only passes the connection file, and
> lets the existing machinery do the work: https://gist.github.com/2831998
>
> The main change that had to happen was specifying KM.session.key
> *before* launching the kernel, since it's used when writing the
> connection file.

Okay, of course, if you're writing a file, that makes sense.  Thanks!


> I would also note that I think the entry point should probably *not* be
> embed_kernel, rather a variation of the standard
> ipkernel.launch_new_instance entry point, which doesn't skip all of the
> normal namespace initialization like embed_kernel does, for the sake of
> embedding.

Thanks for the pointer.  I'll look at this and see the difference 
between it and embed_kernel.  I was just trying to somehow get a kernel 
launched without using Popen, and embed_kernel was an obvious choice 
from the name.

Thanks again for your help!  It really helps us to understand the 
philosophy behind the code, as well as the code itself.

Thanks,

Jason