Du point de vue de la charge du serveur, l'utilisation de l'option IO.FileSystemWatcher pour les notifications de changement à distance dans le scénario que vous décrivez est probablement la méthode la plus efficace possible. Elle utilise le FindFirstChangeNotification y ReadDirectoryChangesW Les fonctions internes de l'API Win32, qui communiquent à leur tour avec le redirecteur de réseau de manière optimisée (en supposant un réseau Windows standard : si un redirecteur tiers est utilisé et qu'il ne prend pas en charge la fonctionnalité requise, les choses ne fonctionneront pas du tout). Le wrapper .NET utilise également des entrées/sorties asynchrones, ce qui garantit une efficacité maximale.
Le seul problème de cette solution est qu'elle n'est pas très fiable. Outre le fait de devoir faire face à des connexions réseau temporairement interrompues (ce qui n'est pas un gros problème, puisque IO.FileSystemWatcher déclenchera dans ce cas un événement d'erreur que vous pourrez gérer), le mécanisme sous-jacent présente certaines limitations fondamentales. Extrait de la documentation MSDN pour les fonctions de l'API Win32 :
-
ReadDirectoryChangesW échoue avec ERROR_INVALID_PARAMETER lorsque la longueur du tampon est supérieure à 64 Ko et que l'application surveille un répertoire sur le réseau. Ceci est dû à une limitation de la taille des paquets avec les protocoles de partage de fichiers sous-jacents.
-
Les notifications peuvent ne pas être renvoyées lors de l'appel FindFirstChangeNotification pour un système de fichiers distant
En d'autres termes, en cas de charge élevée (lorsque vous avez besoin d'une grande mémoire tampon) ou, pire, dans des circonstances aléatoires non spécifiées, vous risquez de ne pas recevoir les notifications attendues. C'est même un problème avec les surveillants de systèmes de fichiers locaux, mais c'est beaucoup plus problématique sur le réseau. Une autre question ici sur SO détaille un peu plus les problèmes de fiabilité inhérents à l'API.
Lorsque vous utilisez des surveillants de systèmes de fichiers, votre application doit être capable de gérer ces limitations. Par exemple :
-
Si les fichiers que vous recherchez ont des numéros de séquence, enregistrez le dernier numéro de séquence pour lequel vous avez reçu une notification, afin de pouvoir rechercher les "trous" dans les notifications futures et traiter les fichiers pour lesquels vous n'avez pas reçu de notification ;
-
Lorsque vous recevez une notification, effectuez toujours une analyse complète du répertoire. Cela peut sembler mauvais, mais comme l'analyse est pilotée par les événements, elle est beaucoup plus efficace que l'interrogation ordinaire. De plus, tant que vous maintenez le nombre total de fichiers dans un seul répertoire, ainsi que le nombre de répertoires à analyser, en dessous de mille environ, l'impact de cette opération sur les performances devrait être assez minime de toute façon.
La mise en place d'auditeurs multiples est à éviter autant que possible : cela ne fera qu'empirer les choses moins fiable...
Bref, si vous voulez absolument tienen pour utiliser des surveillants de système de fichiers, les choses peuvent fonctionner correctement tant que vous êtes conscient des limitations, et ne vous attendez pas à une notification 1:1 pour chaque fichier modifié/créé.
Donc, si vous avez d'autres options (essentiellement, faire en sorte que le processus d'écriture des fichiers vous notifie d'une manière non basée sur le système de fichiers : n'importe quelle méthode RPC régulière sera une amélioration...), celles-ci valent vraiment la peine d'être examinées du point de vue de la fiabilité.
