Show More
@@ -110,7 +110,69 A message is defined by the following four-dictionary structure:: | |||||
110 | 'metadata' : dict, |
|
110 | 'metadata' : dict, | |
111 | } |
|
111 | } | |
112 |
|
112 | |||
113 |
|
113 | The Wire Protocol | ||
|
114 | ================= | |||
|
115 | ||||
|
116 | This message format exists at a high level, | |||
|
117 | but does not describe the actual *implementation* at the wire level in zeromq. | |||
|
118 | The canonical implementation of the message spec is our :class:`~IPython.kernel.zmq.session.Session` class. | |||
|
119 | Every message is serialized to a sequence of at least six blobs of bytes: | |||
|
120 | ||||
|
121 | .. sourcecode:: python | |||
|
122 | ||||
|
123 | [ | |||
|
124 | b'u-u-i-d', # zmq identity(ies) | |||
|
125 | b'<IDS|MSG>', # delimiter | |||
|
126 | b'baddad42', # HMAC signature | |||
|
127 | b'{header}', # serialized header dict | |||
|
128 | b'{parent_header}', # serialized parent header dict | |||
|
129 | b'{metadata}', # serialized metadata dict | |||
|
130 | b'{content}, # serialized content dict | |||
|
131 | b'blob', # extra raw data buffer(s) | |||
|
132 | ... | |||
|
133 | ] | |||
|
134 | ||||
|
135 | The front of the message is the ZeroMQ routing prefix, | |||
|
136 | which can be zero or more socket identities. | |||
|
137 | This is every piece of the message prior to the delimiter key ``<IDS|MSG>``. | |||
|
138 | In the case of IOPub, there should be just one prefix, | |||
|
139 | which is the topic for IOPub subscribers, e.g. ``stdout``, ``stderr``, ``pyout``. | |||
|
140 | ||||
|
141 | .. note:: | |||
|
142 | ||||
|
143 | In most cases, the IOPub topics are irrelevant and completely ignored, | |||
|
144 | because frontends just subscribe to all topics. | |||
|
145 | ||||
|
146 | After the delimiter is the `HMAC`_ signature of the message, used for authentication. | |||
|
147 | If authentication is disabled, this should be an empty string. | |||
|
148 | By default, the hashing function used for computing these signatures is sha256. | |||
|
149 | ||||
|
150 | .. _HMAC: http://en.wikipedia.org/wiki/HMAC | |||
|
151 | ||||
|
152 | .. note:: | |||
|
153 | ||||
|
154 | To disable authentication and signature checking, | |||
|
155 | set the `key` field of a connection file to an empty string. | |||
|
156 | ||||
|
157 | The signature is generated by computing the HMAC digest of the concatenation of: | |||
|
158 | ||||
|
159 | - A shared key (from the ``key`` field of a connection file) | |||
|
160 | - The serialized header dict | |||
|
161 | - The serialized parent header dict | |||
|
162 | - The serialized metadata dict | |||
|
163 | - The serialized content dict | |||
|
164 | ||||
|
165 | After the signature is the actual message, always in four byte sequences. | |||
|
166 | The four dictionaries that compose a message are serialized separately, | |||
|
167 | in the order of header, parent header, metadata, and content. | |||
|
168 | These can be serialized by any function that turns a dict into bytes. | |||
|
169 | The default and most common serialization is JSON, but msgpack and pickle | |||
|
170 | are common alternatives. | |||
|
171 | ||||
|
172 | After the serialized dicts are zero to many raw data buffers, | |||
|
173 | which can be used by message types that support binary data (mainly apply and data_pub). | |||
|
174 | ||||
|
175 | ||||
114 | Python functional API |
|
176 | Python functional API | |
115 | ===================== |
|
177 | ===================== | |
116 |
|
178 |
General Comments 0
You need to be logged in to leave comments.
Login now