Implémentation des communications entre client et serveur avec l'interface verbs (Linux uniquement)

Le développement d'applications qui utilisent l'interface verbs nécessite de créer des artefacts utilisés dans les connexions RDMA (Remote Direct Memory Access) entre le serveur et le client. Un exemple est fourni pour aider les développeurs à exécuter le processus sur le client et le serveur de la connexion.

Remarque : Début des modifications apportées dans l'actualisation de service 8, fix pack 30L'implémentation RDMA, qui était précédemment obsolète, est supprimée de IBM® SDK, Java™ Technology Edition, Version 8.Fin des modifications pour le service refresh 8 fix pack 30
L'API verbs permet de contrôler la création et l'utilisation des ressources RDMA. Avant de commencer un travail de développement, vous devez bien comprendre les communications RDMA et l'environnement client et serveur de votre application Java. Les types de ressources RDMA suivants sont nécessaires :
  • Domaines de protection
  • ID de connexion
  • Paires de files d'attente
  • Files d'attente d'achèvement
Vous devez déterminer la manière dont ces ressources sont associées les unes aux autres. Par exemple, des paires de files d'attente distinctes peuvent être associées à un seule file d'attente d'achèvement ou partagée. Vous devez également déterminer la manière dont les ressources RDMA doivent être utilisées pour la mise à réseau. Par exemple, une file d'attente d'achèvement peut être interrogée directement, ou vous pouvez demander des notifications sur un canal d'événements et interroger ensuite la file d'attente d'achèvement.
Le diagramme suivant montre un exemple d'implémentation de client et de serveur qui utilise l'API verbs. Certaines étapes communes aux processus client et serveur sont développées dans d'autres diagrammes. Pour une description détaillée des termes utilisés dans ces flux de communication, voir jVerbs termes et artefacts de programmation (Linux uniquement).
Le diagramme montre un exemple des étapes de programmation requises pour la communication RDMA lorsque vous développez des applications avec l'API verbs. Les étapes doivent être exécutées chronologiquement sur le client et le serveur de la connexion. Les événements de communication générés à certaines étapes du processus entre le client et le serveur sont également expliqués. Pour une description complète du flux de communication, lisez le texte associé.
La diagramme suivant développe les étapes de programmations nécessaires lorsque vous allouez des structures RDMA. Ce processus est représenté dans le premier diagramme comme la seule étape appelée "Allouer des structures RDMA" qui porte le numéro 1.
Le diagramme présente un exemple des étapes requises pour allouer des structures RDMA pour le transfert de données. Ces étapes sont nécessaires sur le client et le serveur de la communication. Pour obtenir une description des étapes, lisez le texte associé.
Le diagramme suivant développe les étapes de programmation nécessaires lorsque vous supprimez des structures RDMA. Ce processus est représenté dans le premier diagramme comme la seule étape appelée "Détruire les structures allouées" qui porte le numéro 2.
Le diagramme présente un exemple des étapes requises pour supprimer les structures RDMA après le transfert de données. Ces étapes sont nécessaires sur le client et le serveur de la communication. Pour obtenir une description des étapes, lisez le texte associé.

Les sections suivantes expliquent les flux de communication du serveur et du client illustrés dans les diagrammes.

Flux du serveur

Les événements suivants sont générés sur le serveur de la connexion RDMA :
  1. Un canal d'événement est créé.
  2. Un ID de connexion est créé et associé au canal d'événements. N'importe quel nombre d'ID de connexion peut être associé au canal d'événements.
  3. Le serveur écoute les demandes de connexion des clients.
  4. Lorsqu'une demande de connexion client est reçue, la demande est acceptée. Le type d'événement de la demande est RDMA_CM_EVENT_CONNECT_REQUEST.
  5. Pour chaque demande reçue d'un client, les étapes suivantes sont exécutées :
    1. Le serveur obtient l'ID de connexion.
    2. Les structures RDMA nécessaires sont allouées avant la connexion entre le serveur et le client. Les étapes suivantes sont nécessaires pour créer les structures RDMA :
      • Le contexte du périphérique est obtenu ; il peut être utilisé pour interroger le périphérique, le port ou l'identificateur global unique (GUID).
      • Un domaine de protection est alloué.
      • Un canal d'achèvement est créé pour le postage des événements d'achèvement.
      • Une file d'attente d'achèvement est créée.
      • Une demande de travail est émise pour une notification de file d'achèvement.
      • Une paire de files d'attente est créée.
      • Un tampon d'octets (ByteBuffer) direct est alloué et enregistré pour le transfert de données.
    3. Eventuellement, une unité d'exécution de traitement de file d'attente d'achèvement peut être démarrée. Pour plus d'informations sur les événements qui se produisent, voir Traitement de la file d'attente d'achèvement.
    4. Lorsque les structures RDMA sont prêtes, une demande de réception de travail est postée par le serveur.
    5. Lorsque la demande de travail est acceptée, un événement est envoyé au client pour confirmer que la connexion est établie et prête à recevoir les demande d'envoi et de réception RDMA. Le type d'événement est RDMA_CM_EVENT_ESTABLISHED.
    6. Une demande d'envoi ou de réception est postée, ce qui lance le transfert de données entre les systèmes serveur et client.
    7. Lorsque la demande de travail est terminée, la connexion est arrêtée. Le type d'événement RDMA_CM_EVENT_DISCONNECTED est généré par le serveur.
    8. Les structures RDMA créées pour le transfert des données sont supprimées dans l'ordre suivant :
      1. Les tampons sont nettoyés et désenregistrés.
      2. La file d'attente d'achèvement est supprimée.
      3. Le canal d'achèvement est supprimé.
      4. La paire de files d'attente est supprimée.
  6. Pour déconnecter le serveur des autres opérations RDMA avec les systèmes client, l'ID de connexion est supprimé.
  7. Le canal d'événement est supprimé. Il ne peut pas l'être avant que toutes les acceptations soient reçues.

Flux du client

Les événements suivants se produisent sur le client de la connexion RDMA :
  1. Un canal d'événement est créé.
  2. Un ID de connexion est créé et associé au canal d'événements. N'importe quel nombre d'ID de connexion peut être associé au canal d'événements.
  3. Le client demande l'adresse du serveur en utilisant la méthode ConnectionID.ResolveAddress(). Lorsque le type d'événement RDMA_CM_EVENT_ADDRESS_RESOLVED est reçu, le client envoie un accusé de réception.
  4. Le client interroge la route du serveur en utilisant la méthode ConnectionID.ResolveRoute(). Lorsque le type d'événement RDMA_CM_EVENT_ROUTE_RESOLVED est reçu, le client envoie un accusé de réception.
  5. Des structures RDMA nécessaires sont allouées avant la connexion entre le client et le serveur. Les étapes suivantes sont nécessaires pour créer les structures RDMA :
    • Le contexte du périphérique est obtenu ; il peut être utilisé pour interroger le périphérique, le port ou l'identificateur global unique (GUID).
    • Un domaine de protection est alloué.
    • Un canal d'achèvement est créé pour le postage des événements d'achèvement.
    • Une file d'attente d'achèvement est créée.
    • Une demande de travail est émise pour une notification de file d'achèvement.
    • Une paire de files d'attente est créée.
    • Un tampon d'octets (ByteBuffer) direct est alloué et enregistré pour le transfert de données.
  6. Eventuellement, une unité d'exécution de traitement de file d'attente d'achèvement peut être démarrée. Pour plus d'informations sur les événements qui se produisent, voir Traitement de la file d'attente d'achèvement.
  7. Une demande de réception est envoyée au serveur.
  8. Une demande de connexion est envoyée au serveur. Le type d'événement RDMA_CM_CONNECT_REQUEST est généré et envoyé au serveur.
  9. Le client attend que le type d'événement RDMA_CM_EVENT_ESTABLISHED soit reçu du serveur. Cet événement indique que la connexion est établie et que le transfert des données est prêt.
  10. Une demande de travail d'envoi ou de réception est postée, ce qui lance le transfert de données entre les systèmes serveur et client.
  11. Lorsque la demande de travail est terminée, la connexion est arrêtée. Le type d'événement RDMA_CM_EVENT_DISCONNECTED est généré par le client.
  12. Les structures RDMA créées pour le transfert des données sont supprimées dans l'ordre suivant :
    1. Les tampons sont nettoyés et désenregistrés.
    2. La file d'attente d'achèvement est supprimée.
    3. Le canal d'achèvement est supprimé.
    4. La paire de files d'attente est supprimée.
  13. Pour déconnecter le client des autres opérations RDMA avec le serveur, l'ID de connexion est supprimé.
  14. Le canal d'événement est supprimé.

Traitement des files d'attente d'achèvement

Le diagramme suivant développe les étapes de programmation nécessaires lors du traitement éventuel des files d'attente d'achèvement. Ce processus est indiqué dans le premier diagramme comme étape unique "Traitement des files d'attente" qui porte le nombre 3.
Le diagramme présente un exemple des étapes requises pour traiter les files d'attente d'achèvement. Ces étapes sont facultatives sur le client et le serveur de la communication. Pour obtenir une description des étapes, lisez le texte associé.
Les étapes suivantes sont indiquées dans le diagramme :
  1. Le client ou le serveur utilise les méthodes getCQEvent() et pollCQEvent() pour extraire l'événement de type RDMA_CM_EVENT ESTABLISHED du canal de file d'attente d'événements, ce qui déclenche le traitement.
  2. L'achèvement de travail est traité.
  3. Une acception est envoyée à la file d'attente d'achèvement pour confirmer l'achèvement du travail.
  4. Une demande est effectuée pour une notification de file d'attente d'achèvement pour vérifier que la file d'attente d'achèvement a reçue l'acceptation.