メインコンテンツまでスキップ

5. Channel Mechanism (チャネル機構)

5. Channel Mechanism (チャネル機構)​

すべての端末セッション, 転送接続などはチャネル (channel) として扱われる. いずれの側もチャネルを開いてよい. 複数のチャネルは単一の接続に多重化される.

チャネルは各端で番号で識別される. 同一チャネルを指す番号は両側で異なってよい. チャネルを開く要求には送信側のチャネル番号が含まれる. その他のチャネル関連メッセージには, そのチャネルの受信側における番号が含まれる.

チャネルはフロー制御される. ウィンドウ空間が利用可能であることを示すメッセージを受信するまで, チャネルにデータを送ってはならない.

5.1. Opening a Channel (チャネルのオープン)​

新しいチャネルを開きたい側は, チャネルにローカル番号を割り当て, 次のメッセージを相手側に送り, ローカルチャネル番号と初期ウィンドウサイズを含める.

byte      SSH_MSG_CHANNEL_OPEN
string    channel type in US-ASCII only
uint32    sender channel
uint32    initial window size
uint32    maximum packet size
....      channel type specific data follows

channel type は [SSH-ARCH] および [SSH-NUMBERS] に記述される名前であり, 同様の拡張機構を持つ. sender channel は本メッセージ送信者が用いるチャネルのローカル識別子である. initial window size は, ウィンドウを調整せずに本メッセージの送信者へ送れるチャネルデータのバイト数を指定する. maximum packet size は送信者へ送れる個々のデータパケットの最大サイズを指定する. 例えば遅いリンクでは対話接続により小さなパケットを使い, 対話応答を良くしたい場合がある.

遠隔側はチャネルを開けるか判断し, SSH_MSG_CHANNEL_OPEN_CONFIRMATION または SSH_MSG_CHANNEL_OPEN_FAILURE で応答する.

byte      SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32    recipient channel
uint32    sender channel
uint32    initial window size
uint32    maximum packet size
....      channel type specific data follows

recipient channel は元のオープン要求で与えられたチャネル番号であり, sender channel は相手側が割り当てたチャネル番号である.

byte      SSH_MSG_CHANNEL_OPEN_FAILURE
uint32    recipient channel
uint32    reason code
string    description in ISO-10646 UTF-8 encoding [RFC3629]
string    language tag [RFC3066]

SSH_MSG_CHANNEL_OPEN の受信者が指定された channel type をサポートしない場合は, SSH_MSG_CHANNEL_OPEN_FAILURE のみを返す. クライアントは description 文字列をユーザーに表示してもよい. その場合, クライアントは [SSH-ARCH] で論じられた注意を払うべきである.

SSH_MSG_CHANNEL_OPEN_FAILURE の reason code は下表のとおり. 読みやすさのため十進で示すが, 実際は uint32 である.

Symbolic namereason code
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED1
SSH_OPEN_CONNECT_FAILED2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE3
SSH_OPEN_RESOURCE_SHORTAGE4

0x00000005 から 0xFDFFFFFF の範囲で新しい SSH_MSG_CHANNEL_OPEN の reason code (および関連 description テキスト) の割り当てを求める場合は, [RFC2434] に記載の IETF CONSENSUS 手続きを通さなければならない. IANA は 0xFE000000 から 0xFFFFFFFF の範囲で Channel Connection Failure の reason code を割り当てない. その範囲は [RFC2434] に従い PRIVATE USE とする.

IANA は 0xFE000000 から 0xFFFFFFFF を管理しないが, 本範囲は二つに分け, 次の慣例で運用される.

  • 0xFE000000 から 0xFEFFFFFF はローカル割り当てチャネルと併用する. 例えば channel type が "[email protected]" で提案されたが失敗した場合, 応答の reason code は IANA 割り当て (上記および 0x00000001〜0xFDFFFFFF) か, 0xFE000000〜0xFEFFFFFF のローカル値のいずれかである. サーバが提案された channel type を理解しない場合, たとえローカル定義であっても, reason code を送るならば上記のとおり 0x00000003 でなければならない. サーバが channel type を理解するがチャネルが開けない場合は, 提案されたローカル channel type と整合するローカル reason code を返すべきである. 実務者はまず IANA 値を用い, ローカル値を文書化すると想定される.

  • 0xFF で始まる範囲に制限や推奨はない. 相互運用は期待されず, 実験用である.

5.2. Data Transfer (データ転送)​

ウィンドウサイズは, 相手がウィンドウ調整を待つまでに送れるバイト数を示す. 双方は次のメッセージでウィンドウを調整する.

byte      SSH_MSG_CHANNEL_WINDOW_ADJUST
uint32    recipient channel
uint32    bytes to add

このメッセージを受信後, 受信者は以前許可された量より指定バイト数だけ多く送ってもよい. ウィンドウサイズは増加する. 実装は最大 2^32 - 1 バイトのウィンドウを正しく扱わなければならない. ウィンドウを 2^32 - 1 バイトを超えて増やしてはならない.

データ転送は次の型のメッセージで行う.

byte      SSH_MSG_CHANNEL_DATA
uint32    recipient channel
string    data

許可される最大データ量は, チャネルの最大パケットサイズと現在のウィンドウサイズの小さい方で決まる. ウィンドウサイズは送信量だけ減る. 許可ウィンドウが空になった後に送られた余分なデータは, 双方とも無視してよい.

実装は SSH トランスポート層のパケットサイズに何らかの上限を持つと想定される (受信パケットの下限は [SSH-TRANS] に従い 32768 バイト以上でなければならない). SSH 接続層の実装は次を満たさなければならない.

  • トランスポート層が受け取り可能なサイズを超えるパケットにつながる最大パケットサイズを広告してはならない.

  • 遠隔が非常に大きなパケットを受け入れても, トランスポート層が送る用意のあるサイズを超えるデータパケットを生成してはならない.

さらに, 複数種類のデータを転送するチャネルがある. 対話セッションの stderr が例である. そのようなデータは SSH_MSG_CHANNEL_EXTENDED_DATA で渡し, 別の整数でデータ型を指定する. 利用可能な型と解釈はチャネル型に依存する.

byte      SSH_MSG_CHANNEL_EXTENDED_DATA
uint32    recipient channel
uint32    data_type_code
string    data

これらのメッセージで送られたデータは通常データと同じウィンドウを消費する.

現在定義されているのは次の型のみである. data_type_code は読みやすさのため十進だが uint32 である.

Symbolic namedata_type_code
SSH_EXTENDED_DATA_STDERR1

Extended Channel Data Transfer の data_type_code 値は順次割り当てられなければならない. 0x00000002 から 0xFDFFFFFF の範囲で新しい値と関連 data 文字列の割り当ては [RFC2434] の IETF CONSENSUS を通さなければならない. IANA は 0xFE000000 から 0xFFFFFFFF に値を割り当てない. その範囲は PRIVATE USE である. IANA への実際の指示は [SSH-NUMBERS] にある.

5.3. Closing a Channel (チャネルのクローズ)​

一方がチャネルにこれ以上データを送らないときは, SSH_MSG_CHANNEL_EOF を送るべきである.

byte      SSH_MSG_CHANNEL_EOF
uint32    recipient channel

このメッセージに明示的な応答はない. ただしアプリケーションはチャネルの先に EOF を送ってよい. このメッセージの後もチャネルは開いたままであり, 逆方向にはまだデータを送れる. このメッセージはウィンドウを消費せず, ウィンドウがなくても送れる.

いずれかの側がチャネルを終了させたいときは SSH_MSG_CHANNEL_CLOSE を送る. 受信側は, すでに同チャネルに対して送っていない限り, SSH_MSG_CHANNEL_CLOSE を返さなければならない. 送受双方が SSH_MSG_CHANNEL_CLOSE を送受したときその側にとってチャネルは閉じたとみなされ, 番号を再利用してよい. SSH_MSG_CHANNEL_EOF を送受していなくても SSH_MSG_CHANNEL_CLOSE を送ってよい.

byte      SSH_MSG_CHANNEL_CLOSE
uint32    recipient channel

このメッセージもウィンドウを消費せず, ウィンドウがなくても送れる.

可能であれば, このメッセージの前に送られたすべてのデータを実際の宛先に届けることが推奨される.

5.4. Channel-Specific Requests (チャネル固有の要求)​

多くの channel type にはその型に特有の拡張がある. 例は対話セッション向けの pty (擬似端末) 要求である.

チャネル固有の要求はすべて次の形式を用いる.

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    request type in US-ASCII characters only
boolean   want reply
....      type-specific data follows

want reply が FALSE の場合は応答を送らない. それ以外では受信者は SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, または要求固有の継続メッセージで応答する. 要求が認識できないかチャネルでサポートされない場合は SSH_MSG_CHANNEL_FAILURE を返す.

このメッセージはウィンドウを消費せず, ウィンドウがなくても送れる. request type の値はチャネル型ごとにローカルである.

クライアントは要求の応答を待たずにさらにメッセージを送ってよい.

request type 名は [SSH-ARCH] および [SSH-NUMBERS] の DNS 拡張命名規則に従う.

byte      SSH_MSG_CHANNEL_SUCCESS
uint32    recipient channel
byte      SSH_MSG_CHANNEL_FAILURE
uint32    recipient channel

これらのメッセージもウィンドウを消費せず, ウィンドウがなくても送れる.

に最終更新