これはどうしても存在しなければならないドキュメントですが、ワイヤ プロトコルの実装は単一のオブジェクトに実装されているため、そこから理解するのはそれほど難しくありません。リンクしたメッセージ仕様ドキュメントは、各フィールドのアプリケーション レベルのコンテンツをカバーしていますが、実際に zeromq でシリアル化される方法はカバーしていません。そのドキュメントで説明されているように、メッセージがあると仮定すると、ワイヤ形式は非常に単純です。これは、少なくとも 6 つの部分からなるマルチパート zeromq メッセージです。
- 先頭のメッセージ部分は、zeromq ルーティング ID (ゼロ対多) です。
- これらの後には、区切りメッセージが続きます。
<IDS|MSG>
- メッセージの hmac (認証が無効になっている場合
digest
は空の文字列)''
header
parent_header
metadata
content
header
、parent_header
、metadata
、およびcontent
はすべてメッセージング ドキュメントに記載されています。これらは辞書であり、現在使用されているシリアル化でバイトにシリアル化されます。IPython のデフォルトは utf8 でエンコードされた JSON ですが、任意のシリアル化が許可されています (msgpack が最も一般的な非デフォルトです)。ドキュメントにはまだ記載されていませんが、digest
認証に使用されます。これは、メッセージのMD5 HMAC ダイジェストです。ダイジェストのキーはkey
、接続ファイルのフィールドにあります。HMAC ダイジェストで使用される「メッセージ」は、シリアル化されたヘッダー、parent_header、メタデータ、およびコンテンツのバイトを、ネットワーク上で同じ順序で連結したものです。
構成値を指定することにより、メッセージの署名を無効にすることができます
Session.key = ''
コードの IPython 関連部分。この場合、ダイジェスト フィールドは常に空の文字列になります''
。開始時にこれを行うことをお勧めします。そうすれば、実装のより興味深い部分を最初に解決できます。
以下は、IPython によって実際に送信された実行要求とその応答のサンプルです。
リクエスト:
[
<IDS|MSG>
6ea6b213262402cc1ad3c1d3e342a9f6
{"date":"2013-04-27T23:22:13.522049","username":"minrk","session":"5b03b89a-93c9-4113-bb85-17ba57233711","msg_id":"c6d0f85e-fc25-4f1e-84e1-3d706b615393","msg_type":"execute_request"}
{}
{}
{"user_variables":[],"code":"1\n","silent":false,"allow_stdin":true,"store_history":true,"user_expressions":{}}
]
とその返信:
[
5b03b89a-93c9-4113-bb85-17ba57233711
<IDS|MSG>
47d1052f6e8f333d18480938ca91719b
{"date":"2013-04-27T23:22:13.528239","username":"kernel","session":"d7eb303b-d2d0-4723-aef2-738545a8da11","msg_id":"9ed1d332-398c-4132-b203-1e7bf8fed712","msg_type":"execute_reply"}
{"date":"2013-04-27T23:22:13.522049","username":"minrk","session":"5b03b89a-93c9-4113-bb85-17ba57233711","msg_id":"c6d0f85e-fc25-4f1e-84e1-3d706b615393","msg_type":"execute_request"}
{"dependencies_met":true,"engine":"645fb29f-37ab-40c9-bc01-b7fbfe3c2112","status":"ok","started":"2013-04-27T23:22:13.524114"}
{"status":"ok","execution_count":2,"user_variables":{},"payload":[],"user_expressions":{}}
]