Exemples de verrous opportunistes

Les exemples suivants montrent les mouvements de messages SMB et de données en tant que verrous opportunistes et rompus. Notez que les clients peuvent mettre en cache les données d’attribut de fichier ainsi que les données de fichier.

Notez également que ces exemples sont basés sur des situations où les applications clientes demandent des verrous opportunistes à partir de serveurs distants. Ces processus sont lancés automatiquement par le redirecteur réseau et le serveur distant : il n’existe aucune implication directe par l’application cliente ou les applications. Les processus décrits par ces exemples peuvent être généralisés dans des situations où les applications clientes locales demandent directement des verrous opportunistes du système de fichiers local, à l’exception qu’aucun échange de données sur le réseau n’est impliqué.

Verrou opportuniste de niveau 1

Le diagramme suivant montre une vue du trafic réseau d’un verrou opportuniste de niveau 1 sur un fichier. Les flèches indiquent la direction du déplacement des données, le cas échéant.

Dans le cas 1, le client X ouvre un fichier et, dans le cadre de l’opération d’ouverture, demande un verrou opportuniste de niveau 1 sur le fichier. Dans l’événement 2, le serveur accorde le verrou de niveau 1, car aucun autre client n’a le fichier ouvert. Le client continue d’accéder au fichier de la manière habituelle à l’événement 3.

Dans le cas 4, le client Y tente d’ouvrir le fichier et demande un verrou opportuniste. Le serveur voit que le client X a le fichier ouvert. Le serveur ignore la requête de Y tandis que le client X vide toutes les données d’écriture et abandonne son cache de lecture pour le fichier.

Le serveur force X à nettoyer en envoyant à X un message SMB cassant le verrou opportuniste, événement 5. Le client X « silencieusement » ignore toutes les données en lecture-avance ; en d’autres termes, ce processus ne génère aucun trafic réseau. Dans le cas 7, le client X écrit toutes les données d’écriture mises en cache sur le serveur. Lorsque le client X a terminé l’écriture de données mises en cache sur le serveur, le client X envoie un message « fermer » ou « terminé » au serveur, événement 8.

Une fois que le serveur a été averti que le client X a terminé de vider son cache d’écriture sur le serveur ou a fermé le fichier, le serveur peut ouvrir le fichier pour le client Y, à l’événement 9. Étant donné que le serveur dispose désormais de deux clients avec le même fichier ouvert, il accorde un verrou opportuniste à ni l’un ni l’autre. Les deux clients continuent à lire à partir du fichier, et un ou aucun des deux écrits dans le fichier.

Verrou opportuniste batch

Le diagramme suivant montre une vue du trafic réseau d’un verrou opportuniste par lots. Les flèches indiquent la direction du déplacement des données, le cas échéant.

Dans le verrou opportuniste par lot, le client X ouvre un fichier, un événement 1 et le serveur accorde au client X un verrou de lot à l’événement 2. Le client X tente de lire les données, l’événement 3, auquel le serveur répond avec des données, événement 4.

L’événement 5 montre le verrou opportuniste par lot au travail. L’application sur le client X ferme le fichier. Toutefois, le redirecteur réseau filtre l’opération de fermeture et ne transmet pas de message de fermeture, effectuant ainsi une fermeture « silencieuse ». Le redirecteur réseau peut le faire, car le client X possède uniquement la propriété du fichier. Plus tard, à l’événement 6, l’application rouvre le fichier. Là encore, aucune donnée ne circule sur le réseau. En ce qui concerne le serveur, ce client a ouvert le fichier depuis l’événement 2.

Les événements 7, 8 et 9 montrent le cours habituel du trafic réseau. Dans l’événement 10, une autre fermeture silencieuse se produit.

Dans l’événement 11, le client Y tente d’ouvrir le fichier. La vue du serveur du fichier est que le client X l’a ouvert, même si l’application sur le client X l’a fermée. Par conséquent, le serveur envoie un message cassant le verrou opportuniste au client X. Client X envoie désormais le message de fermeture sur le réseau, événement 13. Événement 14 suivant que le serveur ouvre le fichier pour le client Y. L’application sur le client X a fermé le fichier, de sorte qu’elle ne transfère plus vers ou depuis le serveur pour ce fichier. Le client Y commence les transferts de données comme d’habitude dans l’événement 15.

Entre le moment où le client X reçoit le verrou sur le fichier dans l’événement 2 et la fermeture finale à l’événement 13, toutes les données de fichier mises en cache par le client sont valides, malgré les opérations d’ouverture et de fermeture de l’application intermédiaire. Toutefois, une fois le verrou opportuniste rompu, les données mises en cache ne peuvent pas être considérées comme valides.

Filtrer le verrou opportuniste

Le diagramme suivant montre une vue du trafic réseau d’un verrou opportuniste de filtre. Les flèches indiquent la direction du déplacement des données, le cas échéant.

Dans le verrou opportuniste de filtre, le client X ouvre un fichier, un événement 1 et le serveur répond à l’événement 2. Le client demande ensuite un verrou opportuniste de filtre dans l’événement 3, suivi du serveur accordant le verrou opportuniste à l’événement 4. Le client X ouvre ensuite à nouveau le fichier pour la lecture dans l’événement 5, auquel le serveur répond à l’événement 6. Le client tente ensuite de lire les données auxquelles le serveur répond avec des données, événement 8.

L’événement 9 montre le verrou opportuniste de filtre au travail. Le serveur lit avant le client et envoie les données sur le réseau même si le client ne l’a pas demandé. Le client met en cache les données. Dans le cas 10, le serveur prévoit également une demande future de données et envoie une autre partie du fichier pour le client à mettre en cache.

Dans l’événement 11 et 12, un autre client, Y, ouvre le fichier. Le client Y demande également un verrou opportuniste de filtre. En cas de 14, le serveur le refuse. Dans l’événement 15, le client Y demande des données, que le serveur envoie à l’événement 16. Aucun de ces éléments n’affecte le client X. À tout moment, un autre client peut ouvrir ce fichier pour l’accès en lecture. Aucun autre client n’affecte le verrou de filtre du client X.

L’événement 17 affiche les données de lecture X du client. Toutefois, étant donné que le serveur a déjà envoyé les données et que le client l’a mis en cache, aucun trafic ne traverse le réseau.

Dans cet exemple, le client X n’essaie jamais de lire toutes les données du fichier, de sorte que la lecture anticipée indiquée par les événements 9 et 10 est « gaspiller » ; autrement dit, les données ne sont jamais réellement utilisées. Il s’agit d’une perte acceptable, car la lecture anticipée a accéléré l’application.

Dans l’événement 18, le client X ferme le fichier. Le redirecteur réseau du client abandonne les données mises en cache. Le serveur ferme le fichier.