Lancement d’une connexion
Une fois que le commutateur Windows Sockets a reçu un appel WSPConnect lancé par une application, le commutateur compare l’adresse de destination de la demande de connexion avec les adresses de la table des sous-réseaux IP du commutateur que les fournisseurs de services SAN desservent. Si l’un de ces sous-réseaux inclut cette adresse de destination, le commutateur appelle les fonctions WSPSocket et WSPBind du fournisseur de services SAN correspondant pour créer et lier un socket, comme décrit dans Création et liaison de sockets SAN. Le commutateur traite la demande de connexion de l’application à l’aide du socket SAN. Si l’adresse de destination de la demande de connexion ne se trouve pas sur un sous-réseau SAN, ou si le fournisseur de services SAN ne parvient pas à créer et à lier un socket, le commutateur utilise le fournisseur TCP/IP pour établir la connexion.
La figure suivante montre une vue d’ensemble de la façon dont le commutateur Sockets Windows demande une connexion avec un homologue distant. La séquence et les sections qui suivent décrivent la demande de connexion plus en détail.
Après avoir créé et connecté le socket SAN, le commutateur exécute une demande de connexion, à l’aide du socket SAN en mode non bloquant, comme décrit dans la procédure suivante.
Pour exécuter une demande de connexion
Le commutateur appelle la fonction WSPEventSelect du fournisseur de services SAN. Dans cet appel, le commutateur transmet le code FD_CONNECT et l’objet d’événement à associer à ce code. L’appel à WSPEventSelect demande la notification des événements de connexion et informe le fournisseur de services SAN que tout appel WSPConnect suivant s’exécute en mode non bloquant.
Une fois la fonction WSPEventSelect retournée, le commutateur appelle la fonction WSPConnect du fournisseur de services SAN. Dans cet appel, le commutateur transmet l’adresse de destination au format de l’une des familles d’adresses WSK. Le pilote proxy du fournisseur de services SAN mappe cette adresse de destination à une adresse native et tente d’établir la connexion.
Si la fonction WSPConnect du fournisseur de services SAN peut terminer ou échouer immédiatement l’opération de connexion, elle retourne le code de réussite ou d’échec approprié. Si la fonction WSPConnect du fournisseur de services SAN ne peut pas exécuter une demande de connexion immédiatement, l’opération de connexion du fournisseur de services SAN se poursuit de manière asynchrone dans un autre thread. La fonction WSPConnect du fournisseur de services SAN retourne avec l’erreur WSAEWOULDBLOCK pour indiquer que le socket est marqué comme non bloquant et que l’opération de connexion ne peut pas être effectuée immédiatement.
Une fois l’opération de connexion terminée, le fournisseur de services SAN appelle la fonction Win32 SetEvent pour signaler l’objet d’événement précédemment inscrit dans l’appel WSPEventSelect .
Une fois l’objet d’événement signalé, le commutateur appelle la fonction WSPEnumNetworkEvents du fournisseur de services SAN pour obtenir le résultat de l’opération de connexion.
Note Une fois que le commutateur a établi une connexion via un fournisseur de services SAN, le commutateur ne peut plus utiliser le fournisseur TCP/IP pour cette connexion. Les fournisseurs de services SAN doivent implémenter entièrement toutes les fonctionnalités requises pour traiter une connexion établie.
Destruction du socket SAN
Si la fonction WSPConnect du fournisseur de services SAN échoue, le commutateur appelle la fonction WSPCloseSocket du fournisseur de services SAN pour détruire le socket SAN. Le commutateur appelle ensuite la fonction WSPConnect du fournisseur de services TCP/IP pour transférer l’opération de connexion au fournisseur de services TCP/IP, sauf si le fournisseur de services SAN a retourné l’un des codes d’erreur suivants à la suite de son opération de connexion :
WSAECONNRESET
Indique qu’aucune application n’écoute le port spécifié à l’adresse de destination
WSAECONNREFUSED
Indique que l’application distante a refusé activement la demande de connexion
WSAEHOSTUNREACH
Indique que l’adresse de destination n’existe pas
Ces codes d’erreur précédents garantissent qu’une tentative d’établissement de la connexion via TCP/IP échouera également. Un fournisseur de services SAN ne doit pas retourner l’un de ces codes d’erreur s’il ne peut pas effectuer cette garantie. Par exemple, si un ordinateur cible qui ne prend pas en charge les sockets Windows Direct existe sur le SAN mais ne peut communiquer que via NDIS, le fournisseur de services SAN ne peut pas renvoyer WSAEHOSTUNREACH à la suite d’un échec de demande de connexion SAN à cette cible, car une demande de connexion via le fournisseur TCP/IP peut aboutir. Dans ce cas, le fournisseur de services SAN doit retourner WSAETIMEDOUT.
Négociation de session
Une fois que le commutateur a établi une connexion via un fournisseur de services SAN, le commutateur appelle la fonction d’extension WSPRegisterMemory du fournisseur de services SAN pour préinscrire la mémoire pour le tableau de mémoires tampons qui doit recevoir les messages entrants. Le commutateur appelle ensuite la fonction WSPRecv du fournisseur de services SAN pour publier une ou plusieurs mémoires tampons afin de recevoir les données de message entrantes de l’homologue distant. Le commutateur négocie ensuite une session avec son homologue distant en échangeant une paire de messages qui contiennent des informations de contrôle de flux initial. Une fois que le commutateur a négocié une session, il termine l’appel WSPConnect lancé par l’application. L’application peut ensuite commencer à envoyer et à recevoir des données sur la connexion. Pour plus d’informations, consultez Accepter les demandes de connexion.
Une fois la connexion établie via un socket SAN, le commutateur n’appelle pas la fonction WSPConnect du fournisseur de services SAN. Le commutateur gère en interne les applications qui lancent un appel à la fonction WSPConnect du commutateur pour interroger les demandes de connexion.