##// END OF EJS Templates
document the wire protocol
MinRK -
Show More
@@ -110,7 +110,69 b' 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