Implémentation d’un fournisseur de réseau
Un fournisseur réseau est une DLL qui permet au système d’exploitation Windows de prendre en charge un protocole réseau spécifique. Pour ce faire, il implémente l’API du fournisseur de réseau. Cette API est un ensemble de fonctions que le routeur multi-fournisseur (MPR) appelle pour communiquer avec le réseau. Le fournisseur de réseau convertit ensuite ces appels en appels d’API spécifiques au réseau pour effectuer l’action spécifiée par le MPR. De cette façon, le système d’exploitation Windows peut interagir avec de nouveaux protocoles réseau sans avoir à comprendre leurs API spécifiques au réseau.
Pour créer un fournisseur de réseau, écrivez une DLL qui exporte la fonction NPGetCaps .
La prise en charge des autres fonctions dans l’API fournisseur de réseau est facultative. Si votre fournisseur réseau n’a pas besoin d’une fonction, votre DLL n’a pas besoin de l’implémenter ou de fournir une implémentation stub. Pour plus d’informations, consultez les rubriques de fonction individuelle dans Fonctions du fournisseur de réseau.
Sauf que si vous prenez en charge l’une des fonctions d’énumération suivantes, vous devez également prendre en charge les deux autres fonctions : NPOpenEnum, NPEnumResource et NPCloseEnum.
Les instructions suivantes décrivent comment écrire un fournisseur réseau qui interagit bien avec le MPR et le système d’exploitation Windows. Dans la mesure du possible, votre fournisseur doit respecter les instructions suivantes en matière de vitesse, de validation et de routage.
Vitesse
Un fournisseur de réseau doit déterminer rapidement si une ressource réseau est la sienne. Cela est dû au fait que le MPR peut devoir parcourir de nombreux fournisseurs pour trouver le propriétaire d’une ressource.
Si le fournisseur réseau n’est pas propriétaire de la ressource, il doit immédiatement retourner le code WN_BAD_NETNAME status.
Il est également important que les fournisseurs qui prennent en charge NPGetDirectoryType retournent rapidement les résultats de cette fonction, car elle est appelée pendant que WinFile peint l’arborescence de répertoires.
Validation
L’ordre de validation est important. Un fournisseur de réseau doit d’abord déterminer si son réseau est démarré, puis déterminer si le réseau et le fournisseur de réseau prennent en charge l’opération. Si, après ces vérifications, le fournisseur réseau reçoit des ressources réseau, il doit déterminer s’il en est propriétaire. Enfin, il doit valider d’autres paramètres.
Routage
Si le MPR doit parcourir les fournisseurs de réseau, il essaiera tous les fournisseurs jusqu’à ce que l’un d’eux accepte l’appel. En d’autres termes, le MPR continue toujours d’essayer de trouver un fournisseur réseau.
Toutefois, il prend note de la première erreur significative signalée par un fournisseur. Les erreurs telles que ERROR_BAD_NETPATH, ERROR_BAD_NET_NAME, ERROR_INVALID_PARAMETER ERROR_INVALID_LEVEL sont considérées comme insignifiantes, car elles signifient simplement que le fournisseur ne gère pas la ressource. Toutefois, si le fournisseur échoue avec l’erreur ERROR_INVALID_PASSWORD ou toute autre erreur significative, MPR enregistre cette erreur et continue à parcourir les fournisseurs réseau. En règle générale, lors du routage, si aucun fournisseur n’accepte l’appel, le MPR signale la première erreur significative qu’il rencontre lors du passage à vélo des fournisseurs réseau.
Votre fournisseur de réseau doit prendre en compte ce comportement du MPR lors de la décision du message d’erreur à retourner.
Note d’implémentation
Lors de l’implémentation de DLL du fournisseur de réseau, le fournisseur ne doit pas appeler d’autres fonctions de mise en réseau Windows, API Shell ou autres requêtes basées sur le chemin UNC qui pourraient provoquer une réentrée dans le sous-système MPR. Si vous effectuez de tels appels à partir d’une DLL de fournisseur de réseau, l’application ou d’autres composants du système d’exploitation peuvent rencontrer des conflits, des performances médiocres ou des blocages à l’intérieur du sous-système MPR.