Идентификатор процесса (РШ) уникальным образом определяет процесс клиента. Клиенты информируют серверы о создании нового процесса, просто вводя новое значение РШ в диалог о новых процессах.
В базовом протоколе использовалось сообщение 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-битной границы) согласованному размеру буфера с нечетным числом байтов, остающихся (если остаются) в конечном буфере.
При использовании в сети TCP/IP существует вероятность, что в сети применяется DHCP для раздачи IP-адресов клиентским машинам и, возможно, некоторым принтерам. Нечего и говорить, что если TCP/IP является единственным протоколом в сети, то клиентская машина должна иметь допустимый IP-адрес, чтобы общаться с другими устройствами в сети, например компьютерами, маршрутизаторами, принтерами и серверами. Этот IP-адрес должен иметь подходящий сетевой адрес, адрес хоста и маску подсети, иначе коммуникация просто не будет происходить. Если имеется несколько сегментов, то требуется также используемый по умолчанию шлюз.
DHCP может управлять этими простыми задачами, и даже сделать больше. В действительности это четкий и эффективный протокол, которому требуются только четыре кадра для выдачи адреса и два кадра для обновления этого адреса позже. Рассмотрим это подробнее.
Процесс получения адреса Когда загружается клиент DHCP, первое что он должен сделать, это найти сервер DHCP, выдающий IP-адреса для подсети, к которой он присоединен. Для этого устройство пошлет сообщение поиска DHCP, указывающее, что оно хотело бы получить IP-адрес. Сервер DHCP, получив сообщение поиска, ответит предложением DHCP. Оно говорит: "Я получил ваш запрос и вот адрес, который у меня есть". Клиентская машина может получить несколько предложений DHCP от нескольких серверов, которые могут услышать сообщение поиска DHCP. Клиент выберет первое полученное им предложение DHCP и ответит серверу DHCP, что он хочет получить предложенный IP-адрес. Это называется запросом DHCP. Сервер DHCP при получении запроса ответит подтверждением (АСК): "Можете начинать использовать IP-адрес". Таблица резюмирует этот процесс.
Как можно видеть в таблице, DHCP использует широковещание в течение всего процесса. Это позволяет другим машинам в сети знать о том, что происходит. Рассмотрим этот процесс подробнее. В приведенной ниже распечатке заголовка Ethernet можно видеть, что адресом назначения является FFFFFFFFFFFF. Это широковещательный адрес для уровня доступа к среде передачи. Все устройства в сегменте Ethernet должны будут обрабатывать этот кадр, пока не дойдут до раздела UDP (порта дейтаграмм пользователя) и не обнаружат, что они не имеют указанного порта UDP. В распечатке также видно, что размер кадра Ethernet равен 342 байтам. Это размер данного кадра Ethernet, включая заголовок. Число остающихся байтов равно 328, что является полезной нагрузкой минус 14-байтовый заголовок Ethernet.
Выделенный IP-адрес должен обновляться до истечения срока своей службы. Как можно видеть в распечатке выше, когда выделенный адрес подтверждается, одновременно задается время обновления. Процесс обновления требует только двух кадров: запроса DHCP и последующего АСК.
Клиент DHCP будет запрашивать обновление дважды — при запуске и при истечение половины выделенного времени. В каждом из этих случаев, если запрос успешен, он будет использовать только два кадра. Эти два кадра выглядят точно так же, как кадры запроса и подтверждения, показанные в предыдущем разделе. Единственное различие состоит в том, что при запросе во время истечения половины выделенного времени это будет направленная дейтаграмма, а не широковещательное сообщение, как в случае обновления при запуске.
Эти два кадра имеют размер всего 684 байта и требуют только 100 миллисекунд для завершения. Если клиентской машине DHCP не удалось получить обновление после двух попыток, она будет ждать до следующего периода обновления. Если срок выделенного адреса истекает, то машина возвращается к описанному ранее процессу из четырех кадров, как если бы она пыталась получить адрес в первый раз.
Оптимизация трафика DHCP В действительности трафик DHCP имеет минимальное влияние на объем создаваемого сетевого трафика. Существуют только шесть случаев, когда трафик будет присутствовать вообще. Они перечислены ниже:
• Клиенту DHCP требуется адрес в первый раз — четыре кадра.
• Автоматическое обновление при истечении половины выделенного времени — два кадра.
• Перезапуск клиентской машины DHCP — два кадра.
• Машина перемещается в новую подсеть. Это будет создавать два кадра обновления, которые получат отрицательное подтверждение, затем четыре кадра для получения адреса — всего шесть кадров.
• Замена NIC на машине — четыре кадра.
• Адрес IP освобождается или обновляется вручную, с помощью либо ipconfig, либо winipcfg.
Одним из основных способов сокращения объема трафика DHCP является настройка длительности времени выделения. Это делается менеджером DHCP, как показано на рис. Если длительность выделения адреса изменяется с используемых по умолчанию трех дней до тридцати дней, то сокращение трафика может быть существенным — 13684 байта на каждую машину. Такое изменение имеет смысл, когда область адресов значительно больше, чем число хостов, которые необходимо адресовать. Если это не так, то придется либо использовать длительность выделения по умолчанию, либо сделать длительность еще короче. Другой сценарий при настройке длительности выделения номера может возникать в ситуации, когда существует большое количество переносных компьютеров, которые соединяются с сетью на регулярной основе. Если пользователи не обучены освобождать свои IP-адреса при выходе из сети, они могут получать несколько адресов, требуя тем самым большего пространства адресов, чем необходимо.
Получив подходящий IP-адрес, клиентский компьютер должен зарегистрировать в сети свое имя NetBIOS. В большинстве ситуаций эта регистрация будет вовлекать WINS. Большинство ресурсов, доступных в сети, включает некоторый вид компьютерного имени. Компьютеры в сети должны регистрировать по крайней мере одно имя. Как правило они будут регистрировать более одного имени, чтобы обеспечить в сети коммуникацию по имени. В мире Windows NT имя хоста и имя NetBIOS обычно совпадают (они не являются одним и тем же по сути, но обозначаются одним и тем же словом или комбинацией символов). В мире Unix имя хоста и имя NetBIOS могут быть различаться.
В главе 1 говорилось, что NetBIOS (сетевая базовая система ввода-вывода) не то же самое, что NetBEUI. NetBIOS является протоколом, используемым различными приложениями. Он может переноситься через TCP/IP, IPX/SPX и, конечно, NetBEUI. Мы рассмотрим NetBIOS, потому что она используется через TCP/IP.
Чтобы приложения могли общаться, имя NetBIOS должно быть преобразовано в адрес IP. Способ, которым это обычно делается, состоит в испо льзовании либо широковещания b-узлов, либо сервера имен NetBIOS, например WINS. Есть несколько преимуществ использования сервера WINS, а не просто широковещания. Первое состоит в том, что широковещание является очень дорогим предложением, когда речь идет о сетевой производительности. Каждое одиночное устройство в сегменте должно остановить и проверить каждый одиночный кадр широковещания, чтобы определить, не может ли он обслужить запрос. В большой сети широковещание NetBIOS может буквально заполнить всю сеть. С этим надо как-то бороться. К счастью, компания Microsoft разработала для этой цели WINS. WINS полностью соответствует реализации сервера имен NetBIOS на основе RFC. С помощью WINS хосты могут отбрасывать кадр, как только они видят адрес MAC места назначения. Все функции службы имен NetBIOS через TCP/IP используют UDP порт 137. Рассмотрим регистрацию имен и процесс обновления.
Регистрация имен и обновление
Имена NetBIOS должны быть зарегистрированы для каждой службы или приложения, которые хотят использовать их коммуникационный механизм. Примерами таких регистрируемых служб являются служба рабочей станции и служба сервера. Другие имена указывают специальные роли, которые выполняются в сети, такие как основной, или первичный, контроллер домена (Primary Domain Controller, PDC) или резервный контроллер домена (Backup Domain Controller, BDC). Регистрируется само имя домена, а также имена пользователей, регистрирующихся в домене. Эти имена нужны для некоторых функций сообщений и коммуникации. Например, если необходимо послать сообщение, используя сетевую команду send (послать) некому Джейсону, он должен иметь зарегистрированное имя пользователя, иначе ничего не получится. Общее число зарегистрированных имен зависит, очевидно, от числа запущенных служб. Каждое зарегистрированное имя будет использовать всего 214 байтов — 110 байтов для запроса регистрации имени и 104 байта для ответа. Посмотрим теперь на такую транзакцию на листинге ниже:
