Home / 技术调研 / jupyter / jupyter kernel message

jupyter kernel message

概述

每个kernel可以连接到一个或多个前端应用,每个Kernel都可以通过以下socket通道进行通信:

  • shell:来自前端应用的传入请求,代码执行请求。这个socket是来自于前端和内核的 request/reply 的动作
  • IOpub:这个socket是来自内核的广播,包括 stdout、stderr、debug调试。还包括任何 shell socket的传入和内核自己的stdin请求。在协助场景中(多个shell前端),内核通过这个socket向所有前端广播,此内核产生的一些事件信息。所有消息都带有详细的标记,以标记那些是当前的客户端调用,那些是其他的客户端调用。
  • stdin:允许前端以raw_input的方式调用。前端可能使用一些 特殊的输入组件来实现这样的功能
  • Control:类似shell通道,为了执行请求时排队。所以使用此socket执行 关闭、重启、调试的指令
  • Heartbeat:允许前端发送一些简单的字符,以确保此socket 依然处于连接状态

 

消息格式

消息头部(header)

其中session id应在多客户端中具有唯一性。当客户端重新连接(reconnect)到内核时应使用相同的id,客户端重启(restart)时应分配新的id

msg_id 每个消息应是唯一的

父消息头(parent_header)

当一个消息是另一个消息的结果时,例如:output、status、reply。此消息的 parent_header  拷贝自另一个消息的 header,以标识当前消息是针对parent_header进行的回复。reply类型的消息,必须有parent_header。如果消息没有父级关系,应为一个空字典{}。客户端通过 parent_header,将回复的消息路由并在正确的位置进行显示或渲染。

元数据(Metadata)

metadata 这个字典不包含消息的内容,并不经常使用,可以通过metadata额外的存储有关请求或响应的额外位置,例如添加请求或执行上下文的扩展信息

消息正文(Content)

content是消息的正文,它的具体结构由msg_type决定

Buffers

….

完整消息体

 

Shell通道(Request/Reply)

客户端发送 <action_request> 的消息(例如:execute_request、complete_request) 在shell通道,kernel收到消息后,会立刻在IOPub上发布 status: busy的消息,然后kernel处理请求,并发布 <action>_reply的消息(例如:execute_reply),处理完相关请求后,kernel可能会在发布一个 status: idle的消息。这个idle消息,表明在IOPub上给的请求已全部收到

所有的rely 回复消息都会有一个 status字段,该字段具有以下值:

    • status=’ok’:请求已成功处理,
    • status=’error’:请求出现错误,出现错误的请求会包含: ename、evalue、traceback字段
    • status=’abort’:与error相同,但没有错误的消息,不会有其他字段

代码执行(Execute)

这个消息要求内核在为用户保留的命名空间中代表用户执行代码(与内核自己内部的代码区分开)

request

  • code:内核要执行的源代码,一行或多行
  • allow_stdin:在支持标准输入的前端,在内核运行中的代码可以提示用户输入
  • stop_on_error:如果为True,在遇到异常时中止执行队列,如果为False,如果次请求产生一次,排队的execute_request也会执行

reply

 

命令补全(complete_request)

request

reply

 

Introspection

History

Code completeness

Kernel Info

客户端如果希望获取内核的信息可以发送此消息,可以获取内核的语言、语言版本、Ipython的版本等

request

reply

 

IOPub通道(PUB/SUB)

streams(stdout,stderr,etc)

内核通常执行的输出流,会通过stream消息广播,主要是文本消息

stream

Display Data

这种消息类型用于带回应该在前端显示的数据(text、html、svg),这些数据会广播到所有客户端,每条消息可以有多种数据表示形式。有客户端决定使用哪种消息,并如何使用。

 

发表评论