-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kernel handshaking pattern proposal #66
Changes from 11 commits
88b33ef
9ebe5b7
93e61ca
ed24523
0331184
920c07f
2f13d4d
a1fdffa
1bc2a7f
6eb4ff5
5d4d257
aff6a5f
6cd6e7f
6619122
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,59 @@ | ||||||
# Kernel Handshaking pattern | ||||||
|
||||||
## Problem | ||||||
|
||||||
The current implementation of Jupyter client makes it responsible for finding available ports and pass them to a new starting kernel. The issue is that a new process can start using one of these ports before the kernel has started, resulting in a ZMQError when the kernel starts. This is even more problematic when spawning a lot of kernels in a short laps of time, because the client may find available ports that have already been assigned to another kernel. | ||||||
|
||||||
A workaround has been implemented for the latter case, but it does not solve the former one. | ||||||
|
||||||
## Proposed Enhancement | ||||||
|
||||||
We propose to implement a handshaking pattern: the client lets the kernel find free ports and communicate them back via a dedicated socket. It then connects to the kernel. More formely: | ||||||
|
||||||
- The kernel launcher is responsible for opening a dedicated socket for receiving connection information from kernels (channel ports). This socket will be refered as the registration socket. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
- When starting a new kernel, the launcher passes the connection information for this socket to the kernel. | ||||||
- The kernel starts, find free ports to bind the shell, control, stdin, heartbeat and iopub sockets. It then connect to the registration socket and send the connection information to the client. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
- Upon reception of the connection information, the client connects to the kernel. | ||||||
|
||||||
The way the launcher passes the connection information for the registration socket to the kernel should be similar to that of passing the ports of the kernel socket in the current connection pattern: a connection file that can be read by local kernels or sent over the network for remote kernels (although this requires a custom kernel provisioner or "nanny"). This connection file should also contain the signature scheme and the key. | ||||||
|
||||||
The kernel should not expect the registration socket to exist after it has sent its registration (i.e. it can be closed). Therefore, the kernel should disconnect from the registration socket right after it has sent its connection information. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should it wait for a response to acknowledge receipt? That could allow kernels to shut themselves down if the handshake never completes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Indeed, I'll amend the JEP. |
||||||
|
||||||
The kernel specifies whether it supports the handshake pattern via the "kernel_protocol_version" field in the kernelspec: | ||||||
- if the field is missing, or if its value if less than 5.5, the kernel supports passing ports only. | ||||||
- if the field value is >=5.5, the kernel supports both mechanisms. | ||||||
|
||||||
### Remarks | ||||||
|
||||||
This pattern is **NOT** a replacement for the current connection pattern. It is an additional one and kernels will have to implement both of them to be conformant to the Juyter Kernel Protocol specification. Which pattern should be used for the connection if decided by the kernel launcher, depending on the information passed in the initial connection file. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wish we had #92 to indicate support, rather than purely a protocol version number requiring both implementations. |
||||||
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @JohanMabille Do we need to specify that coexisting launcher and kernels not supporting both patterns should be possible. e.g. old launcher (single-mode) should be able to launch new kernels (dual-mode) Similarly, how would.a dual-mode launcher know if the kernel is single- or dual-mode? Is there a "capabilities" JEP for that. I guess it is mandatory for the launcher to know if the kernel support the new handshaking pattern. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As stated in the JEP:
So old launchers can start new kernels, and new launchers will still be able to start old kernels. Reading the kernelspec is enough to know whether a kernel supports both mechanisms or the older one only. |
||||||
|
||||||
A recommended implementation for a multi-kernel client (i.e. jupyter-server) is to have a single long-lived registration socket. | ||||||
|
||||||
### Impact on existing implementations | ||||||
|
||||||
Although this enhancement requires changing all the existing kernels, the impact should be limited. Indeed, most of the kernels are based on the kernel wrapper approach, or on xeus. | ||||||
|
||||||
Most of the clients are based on `jupyter_client`. Therefore, the changes should only be limited to this repository or external kernel provisioners. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
## Relevant Resources (GitHub repositories, Issues, PRs) | ||||||
|
||||||
### GitHub repositories | ||||||
|
||||||
- Jupyter Client: https://github.com/jupyter/jupyter_client | ||||||
The Jupyter protocol client APIs | ||||||
- Voilà: https://github.com/voila-dashboards/voila | ||||||
Voilà turns Jupyter notebooks into standalone web applications | ||||||
- IPyKernel: https://github.com/ipython/ipykernel | ||||||
IPython kernel for Jupyter | ||||||
- Xeus: https://github.com/jupyter-xeus/xeus | ||||||
The C++ implementation of the Jupyter kernel protocol | ||||||
|
||||||
### GitHub Issues | ||||||
|
||||||
- Spawning many kernels may result in ZMQError (https://github.com/jupyter/jupyter_client/issues/487) | ||||||
- Spawning ~20 requests at a time results in a ZMQError (https://github.com/voila-dashboards/voila/issues/408#issuecomment-539968325) | ||||||
|
||||||
### GitHub Pull Requests | ||||||
|
||||||
- Prevent two kernels to have the same ports (https://github.com/jupyter/jupyter_client/pull/490) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.