verbs インターフェースを使用してクライアントとサーバーの通信を実装 (Linux のみ)

verbs インターフェースを使用するアプリケーションを開発するには、サーバーとクライアントの間のリモート・ダイレクト・メモリー・アクセス (RDMA) 接続で使用される成果物を作成するために、一連のステップが必要とされます。 接続のクライアント・サイドとサーバー・サイドの両方のプロセスについて開発者をガイドするために、例を示します。

注： サービス・リフレッシュ 8 フィックスパック 30 の変更点の始まり以前非推奨であった RDMA 実装は、 IBM® SDK, Java™ Technology Edition, Version 8 から削除されました。サービスリフレッシュ8 フィックスパック30の変更終了について
verbs API を使用すると、RDMA リソースがどのように作成されて使用されるかを制御することができます。 開発作業を開始する前に、Java アプリケーションの RDMA 通信、およびクライアントとサーバーの環境についてよく理解しておく必要があります。 以下のタイプの RDMA リソースが必要です。
  • 保護ドメイン
  • 接続 ID
  • キュー・ペア
  • 完了キュー
これらのリソースを相互にどのように関連付ける必要があるかを判別しなければなりません。 例えば、それぞれのキュー・ペアは、単一完了キュー、または共有完了キューに関連付けることができます。 また、ネットワーキングのために RDMA リソースをどのように使用する必要があるかを判別しなければなりません。 例えば、完了キューを直接ポーリングすることも、イベント・チャネルに関する通知を要求して、後から完了キューをポーリングすることもできます。
以下の図は、verbs API を使用するクライアントとサーバーの実装例を示しています。 クライアントとサーバーの両方のプロセスに共通する特定のステップについては、後出の図で詳しく説明しています。 これらの通信フローで使用される用語の詳細については、jVerbsプログラミング用語と成果物（Linuxのみ）を参照してください。
この図は、verb API を使用してアプリケーションを開発する際に RDMA 通信に必要なプログラミング・ステップの例を示しています。 ステップは、クライアントとサーバーの接続の両サイドで、特定の順序で行う必要があります。 クライアント・システムとサーバー・システム間のプロセスの特定段階で生成される通信イベントは、強調表示も行われています。 通信フローの詳細な説明については、関連テキストを参照してください。
以下の図は、RDMA 構造を割り振る際に必要なプログラミング・ステップを詳しく説明しています。 この手順は、最初の図に「RDMA構造の割り当て」というラベルの付いた単一のステップとして示されています。この手順には番号1が付いています。
この図は、データ転送用に RDMA 構造を割り振るために必要なステップの例を示しています。 これらのステップは、通信のクライアント・サイドとサーバー・サイドの両方で必要です。 ステップの説明については、関連するテキストを参照してください。
以下の図は、RDMA 構造を削除する際に必要なプログラミング・ステップを詳しく説明しています。 この手順は、最初の図に「割り当てられた構造を破棄する」というラベルの付いた単一のステップとして示されています。この手順には、番号2が付いています。
この図は、データ転送後に RDMA 構造を削除するために必要なステップの例を示しています。 これらのステップは、通信のクライアント・サイドとサーバー・サイドの両方で必要です。 ステップの説明については、関連するテキストを参照してください。

以下のセクションでは、図に示されたサーバーとクライアントの通信フローについて説明します。

サーバー・フロー

以下のイベントは、RDMA 接続のサーバー・サイドで発生します。
  1. イベント・チャネルが作成されます。
  2. 接続 ID が作成されて、イベント・チャネルとの関連付けが行われます。 任意の数の接続 ID をイベント・チャネルに関連付けることができます。
  3. サーバーが、クライアントからの接続要求を listen します。
  4. クライアントの接続要求を受信すると、要求について確認応答を送信します。 請求用イベント・タイプはRDMA_CM_EVENT_CONNECT_REQUESTです。
  5. クライアントから受信した各要求について、以下のステップが行われます。
    1. サーバーがクライアントの接続 ID を取得します。
    2. サーバーとクライアント間の接続が確立される前に、必要な RDMA 構造が割り振られます。 RDMA 構造を作成するためには、以下のステップが実行される必要があります。
      • デバイスのコンテキストが取得されます。これは、デバイス、ポート、またはグローバル固有 ID (GUID) を照会するために使用できます。
      • 保護ドメインが割り振られます。
      • 完了イベントをポストするために完了チャネルが作成されます。
      • 完了キューが作成されます。
      • 完了キュー通知の作業要求が行われます。
      • キュー・ペアが作成されます。
      • データ転送用に、ダイレクト・バイト・バッファーが割り振られて登録されます。
    3. オプションで、完了キュー処理スレッドを開始することができます。 発生するイベントについて詳しくは、 完了キューの処理を参照してください。
    4. RDMA 構造の準備ができると、受信作業要求がサーバーによりポストされます。
    5. 作業要求が受け入れられると、接続が確立されたこと、および RDMA 送信要求または受信要求を受信する準備ができたことを確認するイベントが、クライアントに送信されます。 イベント・タイプは RDMA_CM_EVENT_ESTABLISHEDです。
    6. 送信要求または受信要求がポストされます。これにより、サーバー・システムとクライアント・システム間のデータ転送が開始されます。
    7. 作業要求が完了すると、接続は切断されます。 イベント・タイプRDMA_CM_EVENT_DISCONNECTEDがサーバーに生成されます。
    8. データ転送用に作成された RDMA 構造は、以下の順序で削除されます。
      1. バッファーが、クリーンアップされて登録抹消されます。
      2. 完了キューが削除されます。
      3. 完了チャネルが削除されます。
      4. キュー・ペアが削除されます。
  6. クライアント・システムとの、これ以降の RDMA 操作からサーバーを切り離すために、接続 ID が削除されます。
  7. イベント・チャネルが削除されます。 イベント・チャネルは、すべての確認応答が受信されるまで削除することができません。

クライアント・フロー

以下のイベントは、RDMA 接続のクライアント・サイドで発生します。
  1. イベント・チャネルが作成されます。
  2. 接続 ID が作成されて、イベント・チャネルとの関連付けが行われます。 任意の数の接続 ID をイベント・チャネルに関連付けることができます。
  3. クライアントが、ConnectionID.ResolveAddress() メソッドを使用して、サーバー・システムのアドレスを照会します。 イベント・タイプRDMA_CM_EVENT_ADDRESS_RESOLVEDを受信すると、クライアントは確認応答を送信します。
  4. クライアントが、ConnectionID.ResolveRoute() メソッドを使用して、サーバー・システムの経路を照会します。 イベント・タイプRDMA_CM_EVENT_ROUTE_RESOLVEDを受信すると、クライアントは確認応答を送信します。
  5. クライアントとサーバー間の接続が確立される前に、必要な RDMA 構造が割り振られます。 RDMA 構造を作成するためには、以下のステップが実行される必要があります。
    • デバイスのコンテキストが取得されます。これは、デバイス、ポート、またはグローバル固有 ID (GUID) を照会するために使用できます。
    • 保護ドメインが割り振られます。
    • 完了イベントをポストするために完了チャネルが作成されます。
    • 完了キューが作成されます。
    • 完了キュー通知の作業要求が行われます。
    • キュー・ペアが作成されます。
    • データ転送用に、ダイレクト・バイト・バッファーが割り振られて登録されます。
  6. オプションで、完了キュー処理スレッドを開始することができます。 発生するイベントについて詳しくは、 完了キューの処理を参照してください。
  7. 受信要求のポストがサーバーに対して行われます。
  8. 接続要求がサーバーに対して行われます。 イベント・タイプRDMA_CM_CONNECT_REQUESTが生成され、サーバーに送信されます。
  9. クライアントは、サーバーからイベント・タイプRDMA_CM_EVENT_ESTABLISHEDを受信するまで待機します。 このイベントは、接続が確立されたこと、およびデータ転送を行う準備ができたことを示します。
  10. 送信作業要求または受信作業要求がポストされます。これにより、サーバーとクライアント・システム間のデータ転送が開始されます。
  11. 作業要求が完了すると、接続は切断されます。 イベント・タイプRDMA_CM_EVENT_DISCONNECTEDは、クライアントに生成されます。
  12. データ転送用に作成された RDMA 構造は、以下の順序で削除されます。
    1. バッファーが、クリーンアップされて登録抹消されます。
    2. 完了キューが削除されます。
    3. 完了チャネルが削除されます。
    4. キュー・ペアが削除されます。
  13. サーバーとの、これ以降の RDMA 操作からクライアントを切り離すために、接続 ID が削除されます。
  14. イベント・チャネルが削除されます。

完了キュー処理

以下の図は、オプションで完了キューを処理する際に必要なプログラミング・ステップを詳しく説明しています。 このプロセスは、最初の図で「完了キュー処理」のラベルの付いた単一ステップとして表示されており、3 の番号が付いています。
この図は、完了キューを処理するために必要なステップの例を示しています。 これらのステップは、通信のクライアント・サイドとサーバー・サイドの両方でオプションのステップです。 ステップの説明については、関連するテキストを参照してください。
この図には、以下のステップが示されています。
  1. クライアントまたはサーバーが、getCQEvent() メソッドおよび pollCQEvent() メソッドを使用して、イベント・キュー・チャネルから RDMA_CM_EVENT ESTABLISHED タイプのイベントを取り出します。このイベントが処理のトリガーとなります。
  2. 作業完了が処理されます。
  3. 作業完了を確認するために確認応答が完了キューに送信されます。
  4. 完了キューが確認応答を受信したことを確認するために、完了キュー通知の要求が行われます。