Exemples de verrou opportunistes

Les exemples suivants montrent les mouvements de messages SMB et de données lorsque des verrous opportunistes sont créés et brisés. 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 automatiquement initiés par le redirecteur réseau et le serveur distant , il n’y a pas d’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 réseau du trafic 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.

Événement Client X Serveur Client Y
1 Ouvre le fichier, le niveau de requête 1 verrou ==>
2 <== Octroi au niveau 1 verrou opportuniste
3 Effectue des opérations de lecture, d’écriture et d’autres opérations ==>
4 <== Demandes d’ouverture de fichier
5 <== Saute le verrou opportuniste
6 Ignorer les données en lecture-avance
7 Écrit des données ==>
8 Envoie le message « close » ou « terminé » ==>
9 Oks open operation ==>
10 Effectue des opérations de lecture, d’écriture et d’autres opérations ==> <== Effectue des opérations de lecture, d’écriture et d’autres opérations

 

Dans l’événement 1, le client X ouvre un fichier et, dans le cadre de l’opération ouverte, 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 à accéder au fichier de la manière habituelle à l’événement 3.

Dans l’événement 4, le client Y tente d’ouvrir le fichier et demande un verrou opportuniste. Le serveur voit que le fichier X du client est ouvert. Le serveur ignore la demande de Y pendant 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 « en mode silencieux » ignore les données en lecture-avance ; en d’autres termes, ce processus ne génère aucun trafic réseau. Dans l’événement 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, en cas 9. Étant donné que le serveur dispose désormais de deux clients avec le même fichier ouvert, il accorde un verrou opportuniste à ni à aucun. Les deux clients continuent à lire à partir du fichier et un ou aucun écrit dans le fichier.

Verrouillage opportuniste batch

Le diagramme suivant montre une vue de 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.

Événement Client X Serveur Client Y
1 Ouvre un fichier, demande un verrou de lot ==>
2 <== Octroie un verrou opportuniste par lot
3 Lit le fichier ==>
4 <== Envoie des données
5 Ferme le fichier
6 Ouvre le fichier
7 Recherche de données
8 Lit les données ==>
9 <== Envoie des données
10 Ferme le fichier
11 <== Ouvre le fichier
12 <== Saute le verrou opportuniste
13 Ferme le fichier ==>
14 Oks open operation ==>
15 <== Effectue des opérations de lecture, d’écriture et d’autres opérations

 

Dans le verrou opportuniste par lot, le client X ouvre un fichier, l’événement 1 et le serveur accorde au client X un verrou de lot dans l’événement 2. Client X tente de lire des données, é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 Client X ferme le fichier. Toutefois, le redirecteur réseau filtre l’opération de fermeture et ne transmet pas de message proche, ce qui permet d’effectuer 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 rouvert le fichier. Là encore, aucune donnée n’est transmise 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 proche sur le réseau, événement 13. L’événement 14 suit lorsque 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.

Événement Client X Serveur Client Y
1 Ouvre le fichier sans droits d’accès ==>
2 <== Ouvre le fichier
3 Requests filter lock==>
4 <== Octroi d’un verrou
5 Ouvre le fichier pour la lecture ==>
6 <== Rouvrez le fichier
7 Lit les données à l’aide du handle de lecture ==>
8 <== Envoie des données
9 <== Envoie des données
10 <== Envoie des données
11 <== Ouvre le fichier
12 Ouvre le fichier ==>
13 <== Verrou de filtre de requêtes
14 Refuse filter lock==>
15 <== Lit les données
16 Envoie des données ==>
17 Lit (mis en cache) les données
18 Ferme le fichier ==>
19 <== Ferme le fichier

 

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 lui 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 n’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. Dans le cas 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 montre 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 « gaspillée » ; 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.