[IPython-dev] Sockets by name, adding a control socket...

Fernando Perez fperez.net@gmail....
Wed Nov 3 23:58:48 CDT 2010

Hi folks,

[ sorry for not having replied to a few mails on the list and starting
a new thread, I'm trying to avoid bottlenecking Min right now.  I'll
catch up with the list asap]

Min and I today had a long discussion about the messaging spec and our
sockets, with an eye towards harmonizing as much as possible the
design of the kernels in the parallel code with that of the
interactive one (as those guys will get merged hopefully soon).

As usual, this is all based on our reference doc:

There are two main points:

1. Our 'XREP' socket does too much, and it would be cleaner if we
break it into two.  Right now that socket manages both control
commands (liek connect or shutdown) and things related to user
'shell-like' activity (code execution, object info, history, etc).  In
the parallel code Min uses a separate control socket, and it seems
clear we should do the same here.  So the plan would be to have two
sockets (we'll get to the names later):

XREP-a: used for
- code execution
- object info
- completion
- history
- anything else that could come up in the future that's along these
lines (i.e. mostly user namespace-related manipulations)

XREP-b: used for:
- connect
- shutdown
- abort
- kernel attribute access
- other kernel-specific manipulations

2. We should name all of our sockets based on what they do, not on the
zmq socket type they use.  Min and I scribbled a bunch on paper and
came up with:

- XREP-a: 'shell'.   It handles all the things that are 'shell-like'.
- XREP-b: 'control'. It handles all kernel control stuff.
- PUB: 'iopub'.  This publishes the i/o streams.
- REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
when needed.
- 'heartbeat': can stay, it's already named by function and not by type

Variations, suggestions, etc, all welcome.

We think Min will start updating the parallel code to follow this
convention, minor tweaks can always be made later but I doubt we'll
want to make major changes.  But feedback on the names is welcome, if
anyone has any.



More information about the IPython-dev mailing list