1. „schlechten Client-Implementierungen“
Aus dem Artikel:
> SMB1 hat sich den Ruf als langsames und „geschwätziges“ Protokoll erworben.
> Es hat eine lange Geschichte und trägt viel Ballast mit sich herum, sein
> schlechter Ruf ist aber viel mehr schlechten Client-Implementierungen
> geschuldet als dem Protokoll selbst.
Was soll das? Was können die „schlechten Client-Implementierungen“
dafür, wenn Microsoft das Protokoll nicht offen legt?
Und was ist genau der Kritikpunkt? Laut Artikel:
> Er las eine Datei sequenziell in 64 KByte großen Blöcken.
Aber nur wenige Zeilen später, steht, dass parallele Abfragen mit SMB
problematisch sind und außerdem:
> Obwohl die maximale Größe für Schreib-/Leseanfragen im SMB2-Protokoll
> theoretisch bei 4 GByte liegt, ist die praktische Nutzung auf 64 KByte
> beschränkt.
Also, was macht der smbclient von Samba denn nun falsch?
2. Leases als Oplock-Nachfahre
Leases mögen ja ein Fortschritt gegenüber Oplocks sein, aber warum
eigentlichen können nicht alle Clients auf derselben Maschine
denselben lokalen Cache verwenden? Diese Funktionalität könnte man in
die SMB-Implementierung, die zwischen den Anwendungen und dem
Netzwerk liegt, verstecken, ohne dass es irgendwelcher magischen 16
Byte langen Keys bedürfte. Lokal-Caching wäre solange möglich, wie
kein zweiter *Rechner* auf dieselbe Datei zugreift. Einzelne
Anwendungen über Keys zu identifizieren, wäre völlig überflüssig.
Oder ist der 16 Byte Key am Ende gar mit der IPv6-Adresse des
Client-Rechners identisch? Dann hätte man das auch gleich sagen
können…
3. „Durable File Handles“
Aus dem Artikel:
> Hat der Client die Verbindung erfolgreich neu aufgebaut, kann er vom Server
> ein Wiederöffnen desselben Handle anfordern. Dies gelingt, solange kein
> anderer Client inzwischen die Datei geöffnet hat, das Batch Oplock also in
> Abwesenheit des ersten Clients gebrochen hat.
Der Sinn entzieht sich mir komplett. Laut diesem Abschnitt kann also
ein „Batch Oplock“ „in Abwesenheit des ersten Clients“ gebrochen
werden. Was genau ist dann an dem Handle „Durable“ und inwiefern
unterscheidet das sich jetzt vom normalen File Handle? War nicht
genau das mögliche zwischenzeitliche Brechen einer Sperre während des
Verbindungsabbruchs genau das Problem, das gelöst werden sollte?
Aus dem Artikel:
> SMB1 hat sich den Ruf als langsames und „geschwätziges“ Protokoll erworben.
> Es hat eine lange Geschichte und trägt viel Ballast mit sich herum, sein
> schlechter Ruf ist aber viel mehr schlechten Client-Implementierungen
> geschuldet als dem Protokoll selbst.
Was soll das? Was können die „schlechten Client-Implementierungen“
dafür, wenn Microsoft das Protokoll nicht offen legt?
Und was ist genau der Kritikpunkt? Laut Artikel:
> Er las eine Datei sequenziell in 64 KByte großen Blöcken.
Aber nur wenige Zeilen später, steht, dass parallele Abfragen mit SMB
problematisch sind und außerdem:
> Obwohl die maximale Größe für Schreib-/Leseanfragen im SMB2-Protokoll
> theoretisch bei 4 GByte liegt, ist die praktische Nutzung auf 64 KByte
> beschränkt.
Also, was macht der smbclient von Samba denn nun falsch?
2. Leases als Oplock-Nachfahre
Leases mögen ja ein Fortschritt gegenüber Oplocks sein, aber warum
eigentlichen können nicht alle Clients auf derselben Maschine
denselben lokalen Cache verwenden? Diese Funktionalität könnte man in
die SMB-Implementierung, die zwischen den Anwendungen und dem
Netzwerk liegt, verstecken, ohne dass es irgendwelcher magischen 16
Byte langen Keys bedürfte. Lokal-Caching wäre solange möglich, wie
kein zweiter *Rechner* auf dieselbe Datei zugreift. Einzelne
Anwendungen über Keys zu identifizieren, wäre völlig überflüssig.
Oder ist der 16 Byte Key am Ende gar mit der IPv6-Adresse des
Client-Rechners identisch? Dann hätte man das auch gleich sagen
können…
3. „Durable File Handles“
Aus dem Artikel:
> Hat der Client die Verbindung erfolgreich neu aufgebaut, kann er vom Server
> ein Wiederöffnen desselben Handle anfordern. Dies gelingt, solange kein
> anderer Client inzwischen die Datei geöffnet hat, das Batch Oplock also in
> Abwesenheit des ersten Clients gebrochen hat.
Der Sinn entzieht sich mir komplett. Laut diesem Abschnitt kann also
ein „Batch Oplock“ „in Abwesenheit des ersten Clients“ gebrochen
werden. Was genau ist dann an dem Handle „Durable“ und inwiefern
unterscheidet das sich jetzt vom normalen File Handle? War nicht
genau das mögliche zwischenzeitliche Brechen einer Sperre während des
Verbindungsabbruchs genau das Problem, das gelöst werden sollte?