Идентификатор процесса (РШ) уникальным образом определяет процесс клиента. Клиенты информируют серверы о создании нового процесса, просто вводя новое значение РШ в диалог о новых процессах.
В базовом протоколе использовалось сообщение SMB SMB_COM_ PROCESS_EXIT для указания катастрофического завершения процесса на клиенте. В однозадачной системе DOS было возможно возникновение тяжелых ошибок, вызываемых разрушением процесса, с остающимися открытыми файлами. Поэтому в таком случае посылается сообщение SMB SMB_COM_PROCESS_EXIT, чтобы позволить серверу закрыть все файлы, открытые этим процессом.
В LANMAN 1.0 и более новых диалектах не посылается никаких сообщений SMB SMB_COM_PROCESS_EXIT. Операционная система клиента должна гарантировать, что будет послано соответствующее сообщение SMB закрытия и очистки, когда последний процесс, обращающийся к файлу, его закроет. С точки зрения сервера не существует понятия идентификатора файла (FID), принадлежащего процессу. FID, возвращаемый сервером одному процессу, может использоваться любым другим процессом, использующим то же транспортное соединение и TID. Не существует SMB создания процесса, посылаемого серверу; клиент должен гарантировать, что только допустимые клиентские процессы получают доступ к FID (и TID). При получении SMB_COM_TREE_DISCONNECT (или когда сеанс сервера и клиента прекращается) сервер будет делать недействительными все файлы, открытые процессом на этом клиенте.
Поле MID
Клиенты, использующие LANMAN 1.0 и более новые диалекты, обычно являются мультизадачными и допускают несколько асинхронных запросов ввода/вывода на задачу. Поэтому вместе с PID используется мультиплексный идентификатор (MID), чтобы разрешить мультиплексирование одного соединения клиента и сервера среди нескольких клиентских процессов, потоков управления и запросов потоков управления.
Несмотря на согласованный диалект, сервер отвечает за обеспечение того, что каждый ответ содержит те же самые значения MID и PID, которые они запрашивают. Клиент может затем использовать значения MID и PID для связывания запросов и ответов и иметь в любое время согласованное количество ожидающих запросов для определенного сервера.
LANMAN 1. 0 и более поздние диалекты протокола CIFS допускают передачу на сервер нескольких запросов SMB в одном сообщении. Сообщения этого типа называются AndX SMB, они подчиняются следующим правилам:
• Вложенные команды не повторяют информацию заголовка SMB. Вместо этого следующее сообщение SMB начинается на поле WordCount.
• Все множественные (сцепленные) запросы должны соответствовать согласованному размеру передачи. Например, если было послано сообщение SMB_COM_TREE_CONNECT_ANDX, включающее SMB_COM_OPEN_ANDX, которое включает SMB_COM_WRITE, то все они должны соответствовать согласованному размеру буфера. Это будет ограничивать размер записи.
• Существует одно посылаемое сообщение, содержащее сцепленные запросы, и одно сообщение ответа на сцепленные запросы. Сервер может НЕ посылать отдельные ответы на каждый из сцепленных запросов.
• Все сцепленные ответы должны соответствовать согласованному размеру передачи. Это ограничивает, например, максимальное значение вложенного SMB_COM_READ. Клиент не должен запрашивать больше байтов, чем может поместиться во множественном ответе.
• Сервер неявно будет использовать результат первой команды в команде "X". Например, TID, полученный через SMB_COM_TREE_ CONNECT_ANDX, мог бы использоваться во вложенном SMB_COM_ OPEN.ANDX, a FID, полученный в SMB_COM_OPEN_ANDX, мог бы использоваться во вложенном SMB_COM_READ.
• Каждый сцепленный запрос может ссылаться только на тот же FID и TID, что и другие команды в комбинированном запросе. Сцепленные запросы могут рассматриваться как выполняющие одну (из нескольких частей) операцию на одном ресурсе.
• Первая КОМАНДА, встретившая ошибку, будет останавливать всю дальнейшую обработку встроенных команд. Сервер не будет возвращать команды, которые выполнились успешно. Поэтому, если сцепленный запрос содержал SMB_COM_OPEN_ANDX и SMB_COM_READ, и сервер смог успешно открыть файл, но чтение встретило ошибку, то после этого файл остался бы открытым. Это в точности то же самое, как если бы запросы были посланы раздельно.
Если при обработке сцепленных запросов возникает ошибка, то последним (из сцепленных запросов в буфере) будет запрос, встретивший ошибку. Другие необработанные сцепленные запросы будет проигнорированы, когда сервер встретит ошибку, и не будут представлены в сцепленном ответе. В действительности последняя допустимая команда ANDXCOMMAND (если существует) будет представлять SMB, на котором встретилась ошибка. Если нет действительной команды ANDXCOMMAND, то возникшая при первом запросе/ответе ошибка и COMMAND содержат отказавшую команду. Во всех случаях информация об ошибке возвращается в заголовке SMB в начале буфера ответа.
Каждый сцепленный запрос и ответ содержит смещение (с начала заголовка SMB) к следующему сцепленному запросу/ответу (в поле AndXOffset в различных протоколах "and X", например, SMB_COM_OPEN_ANDX). Это позволяет создавать запросы распакованными. Между концом предыдущего запроса (как определено WordCount и ByteCount) и началом следующего сцепленного запроса может быть пробел. Это упрощает создание сцепленных запросов протокола. Отметим, что так как клиент должен знать размер возвращаемых данных, чтобы послать правильное число получений (например, SMB_COM_TRANSACTION, SMB_COM_READ_MPX), данные в каждом ответе SMP ожидаются обрезанными до максимального числа 512-байтных блоков (секторов), которые будут соответствовать (начиная с 32-битной границы) согласованному размеру буфера с нечетным числом байтов, остающихся (если остаются) в конечном буфере.
При запуске Systems Management Server Network Monitor версии 2.0 (V5.00646) можно подумать, что встретился со старым другом. Это полная версия Windows 2000 Network Monitor. Интерфейс практически такой же, и большинство утилит работает так же. Однако некоторые вещи изменились и появились новые свойства.
Новые свойства
Программы-эксперты — шесть экспертов, поставляемых вместе с Network Monitor 2.0, перечислены ниже.
• Эксперт среднего времени ответа сервера вычисляет среднее время, которое требуется серверу для ответа на запрос пользователя данных. Он может использовать SMB, специальные порты TCP или специальные сокеты IPX для получения этих чисел, выраженных в секундах.
• Распределение свойств вычисляет статистики кадров для определенного свойства, найденного в кадрах перехваченных данных. Эти свойства могут быть весьма специальными, такими как прием HTTP.
• Утилита объединения протоколов рекомбинирует данные транзакции которые были посланы по сети в множестве кадров. Этот эксперт может собрать все фрагменты вместе на основе информации, которая содержится в кадрах.
• Эксперт распределения протоколов проверяет перехваченные данные и предоставляет статистики о пакетах почти таким же образом, как мастер распределения протоколов в продукте 1.2.
• Эксперт пересылки TCP находит кадры TCP, которые были переслан на один и тот же компьютер. Это полезно при выявлении проблемнь компьютеров.
• Эксперт верхних пользователей находит верхних отправителей и получателей данных в файле перехвата, проверяя адреса источника и места назначения, содержащиеся в кадрах.
SMS 2.0 Platform Software Development Kit (SDK) позволяет разработать своих собственных экспертов, их можно также купить у независимых поставщиков. Эксперты запускаются из меню tools expert при работе в режиме показа. Как можно видеть на рис., эксперт среднего времени ответа сервера может быстро выделить проблему со временем ответа сети. На рисунке сервер 11.0.0.206 имеет среднее время ответа 2.378751 секунд, в то время как все остальные места назначения имеют времена ответа в долях секунды. Чтобы еще больше ухудшить ситуацию, этот медленный сервер используют десять пользователей. Раньше этот процесс превращался в десяток телефонных вызовов (что затрудняло выявление и исправление проблемы). Но теперь, когда благодаря мониторингу и анализу наши действия носят профилактический характер, можно решить проблему без всяких телефонных звонков. Пользователь только после решения проблемы заметит, что сервер стал видимо работать быстрее.
Эксперт пересылки TCP на рис. сообщает, что на самом деле существует несколько пересылок, но ни одна из них не идет на машину или из машины с длинным временем ответа. Так как это происходит не на коммутируемой магистрали, то пересылки могут быть вызваны сетевой перегрузкой, указывающей на возможную причину некоторых задержек.
Утилита объединения протоколов сообщает нам, что в перехваченных данных не существует фрагментированных пакетов, поэтому эта возможная причина может быть отброшена.
Рассматривая эксперт верхних пользователей, мы видим, что пять из десяти верхних пользователей соединены с сервером 11.0.0.206, и наш эксперт протоколов также говорит, что существует большое число соединений RPC с одной и той же машиной. Мы исследуем этот вопрос и находим, что 11.0.0.206 является более старой машиной, находится на 10-мегабитном сегменте Ethernet и даже не имеет в себе платы PCI Ethernet. Очевидно, что мы обнаружили причину слабой производительности. Пользователи не жаловались на нее раньше, потому что "она всегда медленная" и они "научились с этим жить". Замена старой платы на 100-мегабитную плату PCI решает эту проблему достаточно просто.
Как можно видеть на рис, эксперты записывают свою работу в окне статуса экспертов. Мониторинг этого окна удержит вас от попытки выполнить две программы-эксперта в одно время (что породит сообщение об ошибке). Это важно помнить, так как выполнение эксперта на большом файле перехвата может потребовать много времени на медленной машине, а окно статуса эксперта является единственным местом, которое позволит узнать, что компьютер не заблокирован. В это время можно заметить, что использование центрального процессора доходит до 100%, поэтому не надо выполнять экспертов на производственных серверах, так как это вызовет жалобы сообщества пользователей.
