Сетевая производительность увеличивается, если клиент может локально буферизовать данные файла. Это связано с тем, что клиент не должен записывать информацию в файл на сервере, если знает, что никакой другой процесс не получает доступа к данным. Таким же образом клиент может буферизовать данные опережающего считывания из файла, если знает, что никакой другой процесс не записывает данные.
Оппортунистические блокировки, или oplocks, позволяют клиентам динамически изменять их стратегию буферизации согласованным образом. Все версии SMB из LAN-MAN 1.0 способствуют поддержке oplocks.
Три различных вида оппортунистических блокировок перечислены ниже.
1. Исключающая oplock позволяет клиенту открыть файл для своего собственного персонального использования, чтобы выполнить произвольную буферизацию.
2. Пакетная oplock позволяет клиенту держать на сервере открытый файл, даже если локальное средство доступа (accessor) на клиентской м шине закрыло файл.
3. Level II oplock позволяет нескольким машинам читать файл, если среди них нет записывающих клиентов. Level II oplock поддерживаются в том случае, если согласованный диалект будет LM 0.12 или больше.
Открыв файл, клиент запрашивает сервер задать на файле определенную oplock. Ответ сервера указывает тип oplock, предоставленный клиенту, позволяя ему соответствующим образом настроить свою политику буферизации.
SMB_COM_LOCKING_ANDX SMB используется для передачи информации ответа и прерывания oplock. Рассмотрим каждый из этих механизмов блокирования более подробно.
Когда клиенту предоставляется исключающая oplock, он может буферизи-ровать блокированную информацию, выполнять опережающее чтение и записывать данные на клиентской стороне общения, так как знает, что к файлу не будет других средств доступа. Это происходит следующим образом. Редиректор на клиенте открывает файл, запрашивая для клиента oplock. Если файл открыт кем-то другим, клиенту отказывают в oplock, и на локальном клиенте никакой локальной буферизации выполняться не может. Это означает также, что на файле не может выполняться никакого опережающего чтения, если только редиректор не знает, что он имеет блокированный диапазон опережающего чтения. Если сервер предоставляет исключающую oplock, клиент может выполнить некоторую оптимизацию для файла, например блокирование буферизации, чтение и запись данных.
Как можно видеть, когда клиент А открывает файл, он может запросить исключительную блокировку оріоскв. Если больше никто не открыл этот файл на сервере, то оріоск предоставляется клиенту А. Если в некоторый момент в будущем другой клиент, например клиент В, запрашивает открытие того же самого файла, то серверу необходимо, чтобы клиент А прервал свою блокировку оріоск. Прерывание оріоск включает отправку клиентом А на сервер любых данных для записи или блокировки, которые он буфери-зировал, и затем уведомление сервера, что подтверждается отмена блокировки. Это синхронизирующее сообщение информирует сервер, что теперь допустимо разрешить клиенту В завершить открытие файла.
Клиент А должен также стереть все буферы опережающего чтения, которые он имел для файла.
Пакетная блокировка орlоск используются там, где обычные программы на клиенте ведут себя таким образом, что объем сетевого трафика растет выше приемлемого уровня для предоставляемой программой функциональности.
Например, командный процессор выполняет команды из командной процедуры, делая следующие шаги:
• Открывает командную процедуру
• Ищет "следующую строку" в файле
• Считывает строку из файла
• Закрывает файл
• Выполняет команду
Этот процесс повторяется для каждой команды, выполняемой из файла командной процедуры. Очевидно, что это приводит к обработке множества файлов, создавая тем самым сетевой трафик, который можно было бы сократить, если бы программа просто оставляла файл открытым, считывала строку, выполняла команду и затем считывала новую строку.
Пакетное блокирование действует именно так, позволяя клиентам пропускать излишние запросы открытия и закрытия. Когда командный процессор запрашивает следующую строку в файле, клиент либо запрашивает сервер, либо уже имеет эти данные в кэше опережающего чтения. В любом случае объем сетевого трафика клиента существенно сокращается.
Если сервер получает запрос для переименования или удаления файла, который имеет пакетную блокировку ор1оск, он информирует клиента, что необходимо удалить ор1оск. Клиент затем переходит в режим открыть и закрыть, описанный ранее.
Клиент А открывает файл и запрашивает орlоск. Если никто не открывал этот файл на сервере, то клиенту А предоставляется ор1оск. В приведенном выше случае клиент А сохраняет файл открытым для своей вызывающей программы для нескольких операций открыть/закрыть. Данные могут читаться для вызывающей программы с опережением; может также использоваться и другая оптимизация, например буферизированная блокировка.
Однако когда другой клиент запрашивает на сервере операцию открытия, переименования или удаления файла, клиент А должен очистить свои буферизированные данные и синхронизироваться с сервером. В большинстве случаев это включает закрытие файла при условии, что вызывающая программа клиента А считает, что она закрыла файл. Когда файл закрыт, может быть завершен запрос клиента В на открытие.
Блокировки Level П oplock позволяют нескольким клиентам иметь открытым один файл при условии, что ни один клиент не выполняет операций записи в файл. Это важно для сред со старыми машинами. Большинство открытий в режиме совместимости этих клиентов отображается в запрос открытия для совместно используемого доступа к файлу для чтения/записи. Однако помните, что это может также отменять блокировки oplock для других клиентов, даже если ни один из клиентов в действительности не намерен писать в файл.
Последовательность действий почти такая же, как у исключающей блокировки oplock. Основное различие состоит в том, что сервер информирует клиента, что он должен прекратить блокировку Level II oplock, когда никто не пишет в файл. То есть клиент А, например, может открыть файл для желательного доступа READ и общего доступа READ/WRITE. Это означает, что клиент А не будет выполнять никаких записей в файл.
Когда клиент В открывает файл, сервер должен синхронизироваться с клиентом А, если последний имеет какие-либо буферизованные блокировки Когда он синхронизируется, запрос клиента В на открытие может быть завершен. Клиент В, однако, информируется, что он имеет Level II oplock, а не исключающую блокировку oplock для файла.
В этом случае ни один клиент с блокировкой level П oplock на файле не сможет буферизировать какую-либо информацию блокирования на локальной клиентской машине. Это позволяет серверу гарантировать, что если выполняется какая-либо операция записи, то ему необходимо только уведомить клиентов level II, что блокировка должна быть прервана, без необходимости синхронизации всех аксессоров (средств доступа) файла.
Level II oplock может быть ПРЕРВАНА В НИКУДА (BROKEN ТО NONE), означая, что некоторый клиент, открывший файл, выполнил теперь операцию записи в файл. Так как ни один клиент level II не может создать ситуацию блокирования буфера, то информация на сервере остается в согласованном состоянии. Записывающий клиент, например, не сможет записать в заблокированный диапазон по определению. Однако данные опережающего чтения могут буферизироваться на клиентской машине, снижая тем самым объем сетевого трафика, требуемого файлу. Когда прерывается блокировка level II oplock, буферизирующий клиент должен очистить свои буферы и прекратить выполнение всех операций на файле через сеть. Никакого ответа на прерывание oplock от клиента не ожидается, когда сервер прерывает его из LEVEL II в NONE.
Каждый сервер делает доступными для клиентов в сети множество ресурсов. Ресурсом может быть дерево каталогов, именованный канал, принтер и т.д. Клиентская машина видит сервер как единственного поставщика файла или другого доступного ресурса, поэтому она не знает о каких-либо зависимостях от хранения или службы.
Протокол CIFS требует аутентификации сервера пользователей, прежде чем будет разрешен доступ к файлу, и каждый сервер аутентифицирует своих собственных пользователей. Клиентская система должна посылать информацию аутентификации на сервер, прежде чем сервер разрешит доступ к своим ресурсам.
Протокол CIFS определяет два метода, которые могут быть выбраны сервером для безопасности: общий уровень и уровень пользователя.
Сервер общего уровня делает доступным некоторый каталог на дисковом устройстве (или другой ресурс). Для доступа может потребоваться дополнительный пароль. Таким образом, любой пользователь в сети, знающий имя сервера, имя ресурса и пароль, получает доступ к ресурсу. Серверы с безопасностью общего уровня могут использовать различные пароли для одного и того же общего ресурса, где различные пароли предоставляют различный уровень доступа.
Сервер уровня пользователя делает некоторый каталог на дисковом устройстве (или другой ресурс) доступным, но требует дополнительно, чтобы клиент предоставил имя и соответствующий пароль пользователя для получения доступа. Серверы уровня пользователя могут применить имя учетной записи и пароль, предоставленные клиентом. Серверы уровня пользователя предпочтительнее серверов общего уровня для любой новой серверной реализации, так как организации обычно считают, что сервер уровня пользователя легче администрировать. Серверы уровня пользователя могут применять имя учетной записи для проверки списков контроля доступа на отдельных файлах или иметь один список контроля доступа, который применяется ко всем файлам в каталоге.
Когда сервер уровня пользователя проверяет имя учетной записи и пароль, предоставленные клиентом, идентификатор, представляющий этот аутентифицированный экземпляр пользователя, возвращается клиенту в поле Идентификатор пользователя (UID) ответного SMB. Этот UID должен включаться во все последующие запросы, сделанные от имени пользователя с этого клиента. Сервер общего уровня не возвращает в поле UID никакой полезной информации.
Модель безопасности на уровне пользователя была добавлена после выпуска первоначального диалекта протокола CIFS, и, следовательно, некоторые клиенты могут оказаться неспособными послать имена учетных записей и пароли на сервер. Сервер в режиме безопасности на уровне пользователя, общающийся с одним из таких клиентов, будет позволять клиенту соединяться с ресурсами, даже если клиент не прислал информацию об имени учетной записи и пароле:
1. Если имя компьютера клиента идентично имени учетной записи, известной на сервере, и если предоставленный пароль для соединения с общим ресурсом совпадает с паролем этой учетной записи, неявно будет выполнен "вход пользователя в систему" с помощью этих значений. Если это не сработает, то сервер может отказать в запросе или присвоить используемое по умолчанию имя учетной записи по своему выбору.
2. Значение UID в последующих запросах клиента будет игнорироваться, и весь доступ будет проверяться в предположении имени учетной записи, выбранной выше.
