Version 2.2 des SMB-Protokolls
Seite 2: Leases als Oplock-Nachfahre
Leases als Oplock-Nachfahre
Leases verbessern das schon in SMB1 vorhandene Modell der sogenannten opportunistischen Locks, kurz Oplocks. Die haben nichts mit Dateisperren im engeren Sinn zu tun, sondern sind eine Erlaubnis, Inhalte zwischenzuspeichern. Öffnet ein Client eine Datei, fragt er typischerweise nach einem Oplock. Ist er der einzige, der die Datei geöffnet hat, bekommt er ein exklusives Oplock. Damit sichert der Server dem Client zu, dass niemand anders die Datei gleichzeitig offen hat. Das erlaubt dem Client, Dateiinhalte lokal zu cachen, Schreibzugriffe erst verzögert abzusetzen und Anfragen nach Byte Range Locks ebenfalls lokal zu behandeln. Ein Oplock kann die Leistung eines Programms um ein Mehrfaches verbessern.
Will nun ein zweiter Client die Datei öffnen, informiert der Server den Client mit dem Oplock darüber. Der erste Client schreibt daraufhin seine lokal zwischengespeicherten Daten zurück und hört von diesem Zeitpunkt an mit dem Caching auf. Das heißt, er schickt jede Schreib/Lese-Anfrage einer Anwendung synchron zum Server. Erst nachdem der erste Client die Aufgabe des Oplock bestätigt hat, kann der zweite die Datei erfolgreich öffnen.
Der große Haken bei Oplocks ist, dass sie in der Praxis viel zu oft gebrochen werden und man sie nicht wiedererlangen kann, ohne die Datei komplett neu zu öffnen. Das Brechen erfolgt, sobald ein Client die Datei ein zweites Mal öffnen möchte, unabhängig davon, welcher Client das ist. Wenn also eine Applikation wie Excel eine Datei öffnet und diese in einem separaten Thread ein zweites Mal öffnet (das passiert bei Excel regelmäßig), bricht ein Client sein eigenes Oplock. Das Protokoll erlaubt es nicht, Oplocks von einem Client über mehrere Datei-Handles hinweg gemeinsam zu behandeln.
In SMB 2.1 hat Microsoft mit den „Leases“ diesen Designfehler behoben. Ein Lease entspricht in seiner Wirkung einem Oplock: Es ist die Erlaubnis, eine Datei auf dem Client zu cachen. Auch ein Lease bricht beim erneuten Öffnen einer Datei. Die Neuerung besteht darin, dass Microsoft die Bindung des Lease an den beim Öffnen vergebenen Datei-Handle aufgehoben hat. Ein Client gibt beim Öffnen einer Datei einen 16 Byte langen Key an, der das Lease repräsentiert. Will jetzt eine Applikation eine Datei ein zweites Mal öffnen, kann der Client beim zweiten Aufruf denselben Key angeben. Damit zeigt er an, dass er vom ersten Handle weiß und die Lease-Information zwischen beiden Handles teilen will. In diesem Fall bleibt das Lease gültig.
Dieses Teilen lässt sich auch dazu benutzen, ein gebrochenes Lease wiederzuerlangen. Der Client öffnet eine Datei mit einem gebrochenen Lease Key ein weiteres Mal mit einer Lease-Anforderung. Das erste, ohne Lease bestehende Handle erbt über den geteilten Key das neue Lease. Der Effekt ist, dass dies das Brechen des Leases „heilt“ und der Client erneut Datei-Inhalte cachen kann.
Mit dem BranchCache-Protokoll reduziert Windows 7 erheblich die benötigte Bandbreite von einer Zentrale, in der Fileserver stehen, in eine Zweigstelle mit vielen Clients. Dateien, die Clients in der Zweigstelle schon heruntergeladen haben, stehen dort auch anderen Clients zur Verfügung. Entweder stellt der BranchCache-Server ausführbare Dateien oder sich selten ändernde Dokumente zur Verfügung oder die Clients in der Zweigstelle helfen sich gegenseitig mit den Inhalten aus.
Damit kein Client einem anderen modifizierte Inhalte unterschieben kann, ist das BranchCache-Protokoll kryptografisch abgesichert. Im Rahmen von SMB 2.1 bittet der Client den Server, den Hashwert eines Abschnitts zu berechnen. Damit kann der Client überprüfen, dass er von seinem BranchCache-Partner den korrekten Dateiinhalt bekommen hat.
