送信のペーシング

  • [アーティクル]

ネットワークから提供できる速度で送信データを処理するのに十分なリソースがアプリケーションにある場合 (たとえば、画面)、または上位のプロトコル (たとえば、即時要求モード) によってデータ フローが制限されている場合、アプリケーションがペーシングに関与する必要はありません。また、ローカル ノードで透過的に送信ペーシングを処理することができます。

ただし、アプリケーションの種類によっては、送信のペーシングへの関与が必要になる場合があります。 アプリケーションのリソースが限られている場合 (たとえばプリンター)、アプリケーションは Open(PLU) OK 応答の接続情報制御ブロック (CICB) でアプリケーションのペーシング オプションを指定する必要があります (詳細については、「PLU 接続を開く」を参照してください)。アプリケーションからローカル ノードに対して、最初は Open(PLU) OK 応答で、また定期的に Status-Resource メッセージで、これらのリソースの状態に関する情報を提供する必要もあります。

アプリケーションによる Open(PLU) OK 応答の初期クレジット フィールドの計算を支援するために、ローカル ノードからは Open(PLU) 要求でペーシング ウィンドウ サイズとプライマリおよびセカンダリの最大要求/応答ユニット (RU) のサイズが伝えられます。 初期クレジットは、少なくともプライマリからセカンダリのペーシング ウィンドウ サイズと同じ大きさである必要があります。 そうでない場合、BIND は拒否され、アプリケーションには Open(PLU) エラー確認メッセージが送信されます。 ローカル ノードにより、そのペーシング ウィンドウよりも 1 つ多い値が初期クレジットの推奨値に入力されます (停止と開始の状況を回避するため)。

また、(初期クレジットにかかわらず) ペーシングに関与する必要があるとアプリケーションに指定されていても、BIND に送信ペーシングがないと指定されている場合も、ローカル ノードによって BIND が拒否されることに注意してください。

関数管理データ (FMD) 要求のみがクレジット スキームの一部であるため、アプリケーション側で、初期クレジット数に指定されている RU 数に加え、1 RU あたり 1 つの Status-Control 要求のための領域をバッファー内に確保する必要があります (Status-Control メッセージは 36 バイトを占めます)。

アプリケーションからローカル ノードに配信されるクレジット ユニットごとに、ローカル ノードからアプリケーションに対して 1 つの RU (チャンクを使用している場合は 1 つのチャンク) を与えることができます。 アプリケーションがセグメントを受信している場合、複数の DATAFMI メッセージに対応する可能性があることに注意してください。 アプリケーションにより、送信フロー制御の目的で、開始基本情報ユニット (BBIU) フラグと終了基本情報ユニット (EBIU) フラグを使用して RU をカウントすることができます。

アプリケーションには、クレジット使用カウントを保持し、Status-Resource メッセージでローカル ノードに報告する必要があります。 アプリケーションにより、次のアクションを実行する必要があります。

  • (FMD 要求に対応して) EBIU が設定された DATAFMI メッセージを処理する (受信しない) 場合、クレジット使用カウントを 1 つ増やします。

  • Status-Control メッセージと、ローカル ノードからの他のすべてのメッセージを処理する場合には、クレジット使用カウントを増やさないでください。

  • 定期的に Status-Resource メッセージで現在のクレジット使用カウントを報告します。

  • クレジット使用カウントが 0 の場合を除き、(最後に処理されたメッセージが何であれ) バッファーが空になったときにクレジット使用カウントを報告します。

  • クレジット使用カウントがローカル ノードに報告されたら、0 にリセットします。

    アプリケーションから Status-Resource メッセージを提供する頻度は設計されていません。 一方、ローカル ノードからは、クレジットを受け取った数だけ Data メッセージがアプリケーションに送信されます。 アプリケーションのクレジット使用カウントが初期クレジット値に達すると、それ以降、ローカル ノードからデータは送信されません。 このようになる前に、アプリケーション側で Status-Resource メッセージを送信するようにします。その理由は、ローカル ノードからアプリケーションに対して Data メッセージを送信できず、ホストからはまだ要求が送信されている場合、ローカル ノードからホストに対して必要なときにペーシング応答を送信できず、結果的にパフォーマンスが低下する可能性があるからです。

    ペーシング ウィンドウが 1 または 2 のように小さい場合、アプリケーション側で各 DATAFMI メッセージを処理した後に Status-Resource を送信して、適切なペーシング応答をローカル ノードから送信できるようにします。

    次の図は、アプリケーションが関与していない場合 (APPLPAC = 0x00) に、ローカル ノードによって送信のペーシングが処理されるしくみを示しています。 ペーシング ウィンドウは 2 と想定されています。

    送信ペースを処理するローカル ノードを示す画像。
    送信のペーシングを処理するローカル ノード

    次の図は、送信のペーシングを処理するローカル ノードとアプリケーションを示しています。送信のペーシング ウィンドウは 2 と想定され、ローカル ノードからアプリケーションへの初期クレジットは 4 と想定されています。 残っている現在のウィンドウと次のウィンドウのために十分なクレジットがアプリケーションにある場合、すぐに、ローカル ノードからホストに対して分離ペーシング応答 (IPR) が送信され、データでいっぱいの別ウィンドウが取得される可能性があることに注意してください。

    ローカル ノードと、送信ペースを処理するアプリケーションを示す画像。
    送信のペーシングを処理するローカル ノードとアプリケーション

関連項目

PLU 接続を開く
PLU セッション
送信チェーン
受信チェーン
セグメントの配信
Brackets
方向
ペーシングとチャンキング
データの確認と拒否]
シャットダウンと休止
回復
アプリケーションが開始する終了
LUSTATs]
応答時間モニターのデータ