Exemples de verrous opportunistes

Les exemples suivants montrent des mouvements de données et de messages SMB en tant que verrous opportunistes créés 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 à des serveurs distants. Ces processus sont automatiquement lancés par le redirecteur réseau et le serveur distant. Il n’y a aucune implication directe de la ou des applications clientes. 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 le sens du déplacement des données, le cas échéant.

Événement	Client X	Serveur	Client Y
1	Ouvre le fichier, demande un verrou de niveau 1 ==>
2		<== Octrois de verrou opportuniste de niveau 1
3	Effectue des opérations de lecture, d’écriture et autres ==>
4			<== Demandes d’ouverture du fichier
5		<== Casse le verrou opportuniste
6	Ignore les données en lecture anticipée
7	Écrit des données ==>
8	Envoie le message « close » ou « done » ==>
9		Opération d’ouverture ok ==>
10	Effectue des opérations de lecture, d’écriture et autres ==>		<== Effectue des opérations de lecture, d’écriture et autres

 

Dans l’événement 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 accède au fichier de la manière habituelle dans l’événement 3.

Dans l’événement 4, le client Y tente d’ouvrir le fichier et demande un verrou opportuniste. Le serveur constate que le fichier est ouvert sur le client X. 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 à propre en envoyant à X un message SMB cassant le verrou opportuniste, événement 5. Le client X « silencieusement » ignore toutes les données en lecture préalable ; 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é d’écrire des données mises en cache sur le serveur, le client X envoie un message « close » ou « done » au serveur, événement 8.

Une fois que le serveur a été informé que le client X a terminé de vider son cache d’écriture sur le serveur ou qu’il a fermé le fichier, le serveur peut ouvrir le fichier pour le client Y, dans l’événement 9. Étant donné que le serveur a maintenant deux clients avec le même fichier ouvert, il accorde un verrou opportuniste à ni l’un ni l’autre. Les deux clients effectuent la lecture à partir du fichier, et l’un ou l’autre écrit dans le fichier.

Verrou opportuniste par lot

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

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

 

Dans le verrou opportuniste par lots, le client X ouvre un fichier, événement 1, et le serveur accorde au client X un verrou de lot dans l’événement 2. Le client X tente de lire les 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 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 a la propriété exclusive du fichier. Plus tard, dans 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 le fichier ouvert 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 indique que le client X l’a ouvert, même si l’application sur le client X l’a fermé. Par conséquent, le serveur envoie un message cassant le verrou opportuniste au client X. Le client X envoie maintenant le message de fermeture 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 ayant fermé le fichier, elle n’effectue plus de transferts 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édiaires. Toutefois, une fois le verrou opportuniste rompu, les données mises en cache ne peuvent pas être considérées comme valides.

Verrou opportuniste de filtre

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

Événement	Client X	Serveur	Client Y
1	Ouvre un fichier sans droits d’accès ==>
2		<== Ouvre le fichier
3	Demandes filter lock==>
4		<== Octroi de verrou
5	Ouvre le fichier pour la lecture ==>
6		<== Rouvre 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 des demandes
14		Refuse le verrouillage de filtre==>
15			<== Lit les données
16		Envoie des données ==>
17	Lit les données (mises en cache)
18	Ferme le fichier ==>
19			<== Ferme le fichier

 

Dans le verrou opportuniste de filtre, le client X ouvre un fichier, l’é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 par le serveur qui accorde le verrou opportuniste dans 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 dans 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 du filtre au travail. Le serveur lit avant le client et envoie les données sur le réseau même si le client ne les a pas demandées. Le client met en cache les données. Dans l’événement 10, le serveur anticipe également une demande future de données et envoie une autre partie du fichier pour que le client soit mis en cache.

Dans les cas 11 et 12, un autre client, Y, ouvre le fichier. Le client Y demande également un verrou opportuniste de filtre. Dans l’événement 14, le serveur le refuse. Dans l’événement 15, le client Y demande des données, que le serveur envoie dans l’événement 16. Rien de tout cela 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 la lecture des données du client X. Toutefois, étant donné que le serveur a déjà envoyé les données et que le client les a mises 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 « gaspille » ; 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.