8. Windows NT как элемент гетерогенной сети

8.1. Продукты межсетевого взаимодействия для Windows NT

Одним из общепризнанных достоинств сетевой операционной системы Windows NT является наличие в ней разнообразных встроенных средств межсетевого взаимодействия. Так как неоднородность - это одна из основных особенностей корпоративной сети, то в качестве претендента на роль лидера среди серверных сетевых операционных систем, Windows NT просто обязана была поддерживать кроме родного стека коммуникационных протоколов NetBEUI/SMB, и другие наиболее популярные стеки, такие как TCP/IP или Novell NetWare, а также обеспечивать возможность легкого включения других стеков, поставляемых третьими фирмами.

Существует большое количество средств и продуктов для Windows NT, поддерживающих взаимодействие с другими сетями и операционными системами. В первую очередь это встроенные средства, входящие в стандартную поставку Windows NT Server и Windows NT Workstation, такие как NWLink, NetWare Compatible Service (NWCS), Gateway Services for NetWare, Directory Service Manager for NetWare для взаимодействия с сетями NetWare, протоколы IP, ICMP, TCP, UDP, ftp, telnet для взаимодействия с сетями TCP/IP. Microsoft выпускает и отдельные продукты межсетевого взаимодействия - например, шлюзы для своей почтовой системы Microsoft Mail Server или File and Print Services for NetWare - реализацию протоколов NCP и SAP в среде Windows NT. Появилось и большое количество продуктов третьих фирм для Windows NT, например, BW-Connect NFS компании Beame & Whiteside, PathWorks for Windows NT компании Digital Equipment, NFS connectivity services компании Intergraph, редиректор для сетей Banyan VINES, NetWare Client for Windows NT фирмы Novell. Этот список можно еще продолжать и продолжать.

Для того, чтобы сделать обоснованный выбор, следует учитывать в первую очередь следующие характеристики средств межсетевого взаимодействия:

• способ реализации: мультиплексор протоколов или шлюз;
• требуемый уровень согласуемых протоколов: межсетевое взаимодействие на уровне транспортных протоколов или на уровне прикладных сервисов;
• конкретные протоколы, которые необходимо согласовать;
• направление взаимодействия: предоставление возможности клиентам "чужой" сети обращаться к серверу в вашей сети, либо - наоборот;
• место размещения согласующих средств: на клиентских машинах, на серверах, либо на промежуточной машине-шлюзе; в среде одной, либо другой операционной системы;
• потребительские характеристики: стоимость, производительность, степень прозрачности, удобство инсталляции и обслуживания.

Компьютеры и другие устройства сети взаимодействуют, используя программные и аппаратные коммуникационные средства. Если у двух взаимодействующих сторон эти средства построены на основании одного и того же стека протоколов, то никаких сложностей при организации взаимодействия не возникает, в противном случае - этих проблем не избежать.

При обсуждении проблем межсетевого взаимодействия под термином "сеть" будем понимать совокупность компьютеров и другого сетевого оборудования, которые связаны между собой с помощью общего стека коммуникационных протоколов. Отсюда следует, что если у компьютеров не совпадает протокол хотя бы одного уровня, то они принадлежат разным сетям, а значит, при необходимости их связывания между собой могут возникнуть проблемы межсетевого взаимодействия.

Проблема межсетевого взаимодействия может иметь разные внешние проявления, но суть ее одна - несовпадение используемых коммуникационных протоколов. Например, эта проблема возникает в сети, в которой используется только одна сетевая ОС, но в которой транспортная подсистема неоднородна из-за того, что сеть включает в себя фрагменты Ethernet, объединенные кольцом FDDI. Здесь в качестве взаимодействующих сетей выступают группы компьютеров, использующие различные протоколы канального и физического уровня, например, сеть Ethernet, сеть FDDI.

Равным образом проблема межсетевого взаимодействия может возникнуть в однородной сети Ethernet, в которой установлено несколько сетевых ОС. В этом случае, все компьютеры и все приложения используют для транспортировки сообщений один и тот же набор протоколов, но взаимодействие клиентских и серверных частей сетевых сервисов осуществляется по разным протоколам. Здесь компьютеры могут быть отнесены к разным сетям, если у них различаются протоколы верхних уровней, например, сеть Windows NT, сеть NetWare. Конечно, эти сети могут спокойно сосуществовать, не мешая друг другу и мирно пользуясь общим транспортом. Однако, если потребуется обеспечить доступ к данным файл-сервера NetWare для клиентов Windows NT, администратор сети столкнется с необходимостью согласования сетевых сервисов.

Существует два универсальных подхода к согласованию протоколов, независимо от того, к какому уровню модели OSI они относятся: трансляция и мультиплексирование. Межсетевое взаимодействие на уровне транспортных подсистем может быть организовано помимо уже названных подходов путем использования единого сетевого протокола (например, IP или IPX), а также инкапсуляции.

8.2. Сравнение мультиплексирования и трансляции

Мультиплексирование состоит в установке нескольких дополнительных стеков протоколов на одной из конечных машин, участвующих во взаимодействии. Компьютер с несколькими стеками протоколов использует для взаимодействия с другим компьютером тот стек или тот протокол, который понимает этот компьютер, то есть выбирает язык, понятный его собеседнику. При мультиплексировании протоколов реализуется отношение "один-ко-многим", то есть один клиент с дополнительным стеком может обращаться ко всем серверам, поддерживающим этот стек, или один сервер с дополнительным стеком может предоставлять услуги многим клиентам.

Стеки могут мультиплексироваться как целиком, так и по частям, протоколами отдельных уровней. Хотя в стандартной модели взаимодействия открытых систем OSI определено семь уровней, коммуникационные средства реальных систем обычно подразделяются на три уровня. Нижний уровень составляют драйверы сетевых адаптеров, реализующие функции канального уровня модели OSI, на среднем уровне работают так называемые транспортные средства, выполняющие функции сетевого и транспортного уровней. Верхний уровень образуют серверы и редиректоры, выполняющие функции сеансового, представительного и прикладного уровней модели OSI.

Если в системе предусматривается мультиплексирование средств каждого из трех уровней, то диалог между компьютерами может поддерживаться, например, протоколом SMB на верхнем уровне, протоколами TCP и IP на транспортном уровне и протоколом Ethernet на нижнем уровне. Для организации связей между различными протоколами на каждом уровне вводится дополнительная компонента, называемая мультиплексором или менеджером протоколов. Мультиплексор осуществляет соединение между парами протоколов двух соседних уровней в зависимости от потребностей приложений (заметим, что на верхнем уровне мультиплексор соединяет приложение с различными редиректорами).

Для того, чтобы та или иная компонента могла быть использована в режиме мультиплексирования, она должна быть написана в соответствии с определенными соглашениями, то есть поддерживать требуемый интерфейс с мультиплексором. Сам мультиплексор должен поддерживать два, в общем случае разных, интерфейса - с нижележащими и вышележащими компонентами.

Другой способ организации совместной работы двух разных сетей состоит в выделении специального элемента сети - шлюза, в котором установлены оба согласуемых стека протоколов. Шлюз транслирует один стек протоколов в другой для всех нуждающихся в этом приложений, то есть выступает переводчиком для компьютеров, использующих разные языки общения. Как и обычный перевод, трансляция протоколов - это сложная эвристическая процедура, так как не всегда имеется явное соответствие между типами сообщений разных протоколов. Ключевым моментом трансляции является согласование разных систем адресации ресурсов, принятых в различных сетях. Шлюз обычно решает эту проблему за счет привлечения символьных имен ресурсов, используемых протоколом прикладного уровня при установлении соединения клиента с сервером.

Шлюз реализует взаимодействие "многие-ко-многим", то есть все клиенты сервера, на котором установлен шлюз, могут обращаться с запросами ко всем серверам в другой сети.

Каждый из названных подходов имеет свои достоинства и недостатки.

К достоинствам шлюзов относится то, что при их использовании в сеть вносятся минимальные изменения - дополнительное программное обеспечение устанавливается только на одном из серверов, а клиентские станции остаются без каких-либо изменений. Полностью сохраняется привычная пользовательская среда.

При мультиплексировании протоколов дополнительное программное обеспечение - соответствующие стеки протоколов - должно быть установлено либо на каждую клиентскую машину, которой может потребоваться доступ к серверам другой сети, либо на каждый сервер, к который предполагается использовать для обслуживания клиентов из другой сети. В Windows NT имеются средства борьбы с избыточностью, свойственной этому подходу - операционная система может быть сконфигурирована для работы с несколькими стеками протоколов, но динамически можно загрузить только те, которые сейчас нужны.

В принципе, при работе с несколькими стеками протоколов у пользователя может возникнуть проблема работы в незнакомой среде, с незнакомыми командами, правилами и методами адресации. В Windows NT сделана попытка в какой-то степени облегчить жизнь пользователю в этой ситуации. Независимо от используемого протокола прикладного уровня (например, Microsoft SMB или Novell NCP) ему предоставляется один и тот же интуитивный графический интерфейс, с помощью которого он просматривает и выбирает нужные удаленные ресурсы. Однако, некоторые сервисы пока еще не охвачены этим универсальным средством: большинство сервисов стека TCP/IP - ftp, tftp, r*, ping и другие - используют режим командной строки. Пользователь должен выучить названия команд, их синтаксис и значения многочисленных ключей. Telnet - еще один сервис стека TCP/IP - использует для диалога собственный графический интерфейс, поскольку по своей природе эмуляция терминала значительно отличается от файлового сервиса.

Как и всякий централизованный ресурс, шлюз снижает надежность сети. С другой стороны, централизация облегчает контроль доступа пользователей к "чужой" сети, диагностику и обработку ошибочных ситуаций.

Шлюз является более медленным средством по сравнению с переключаемыми стеками протоколов. Во-первых, из-за относительно больших затрат времени на собственно процедуру трансляции, а, во-вторых, из-за задержек запросов в очереди к разделяемому всеми клиентами шлюзу. Это делает шлюз плохо масштабируемым решением. Трансляция протоколов в шлюзе замедляет доступ к серверу NetWare по сравнению с доступом через редиректор клиента. При тестировании замедление в малозагруженном шлюзе составило от 10% до 15%.

8.3. Уровни согласования протоколов

Средства межсетевого взаимодействия нужны для того, чтобы обеспечить согласованную работу двух приложений, выполняющихся в разнородных сетях. Работа по обеспечению взаимодействия может выполняться как самими приложениями, так и системными средствами. Поэтому требования к системным средствам зависят от того, какой объем согласующих функций берут на себя приложения.

Крайним является чисто умозрительный случай, когда приложения берут на себя все функции по согласованию, кроме тех, которые могут быть выполнены только аппаратно, то есть сетевыми адаптерами. В этом случае приложения сами разбивают сообщения на пакеты, снабжая их соответствующей служебной информацией, организуют их надежную доставку с помощью нумерации, упорядочения, вычисления и проверки контрольных сумм. Помимо функций по оформлению и доставке сообщений, приложения в этом случае выполняют и функции по согласованию возможных различий в сервисах локальных операционных систем, например, различий в именовании файлов, интерпретации прав доступа к файлам, способов их разделения между несколькими пользователями и т. п.

Более реалистическими являются два других случая распределения функций между приложениями и системными средствами.

Первый вариант - системные средства берут на себя все функции по передаче сообщений, согласуя три или четыре нижних уровня модели OSI. Приложения в таком случае реализуют свой собственный протокол взаимодействия, который включает функции трех верхних уровней модели OSI - прикладного, представительного и сеансового. Приложения реализуют согласование только тех сервисов верхнего уровня, которые им необходимы. Примером такого распределенного приложения может служить электронная почта, агенты передачи сообщений которой работают как в среде Windows NT, так и в среде UNIX, непосредственно обращаясь для отправки и получения сообщений к средствам сетевого уровня, например к протоколу TCP (через соответствующий интерфейс, например, Berkeley Sockets). В соответствии с этим вариантом построены и корпоративные СУБД, такие как Oracle, Informix, Sybase.

Второй вариант - приложения вообще не выполняют функции по согласованию неоднородностей вычислительных сред, а полностью перепоручают эту задачу системным средствам, которые в этом случае должны обеспечивать взаимодействие на всех уровнях модели OSI - от физического до прикладного. На прикладном уровне достаточно иметь средства согласования только тех сервисов, которыми пользуется приложение. Например, если электронная почта основана на специальном почтовом сервисе, поддерживаемом операционной системой, таком как SMTP или MHS, то при работе в неоднородной в отношении этого сервиса сети потребуются системные средства согласования именно этих протоколов. Если же программа, реализующая электронную почту, использует для передачи сообщений удаленный файловый сервис, то для ее нормальной работы на прикладном уровне достаточно иметь системные средства согласования протоколов файлового сервиса.

Системные средства могут реализовывать функции по согласованию стеков протоколов частями, с помощью нескольких программных продуктов. Часто один продукт согласует только сервисы прикладного уровня (или один из этих сервисов), а другой - только транспортные протоколы. Например, продукт компании Microsoft File and Print Services for NetWare обеспечивает поддержку в среде Windows NT только прикладных протоколов файлового сервиса и сервиса печати NetWare, но не выполняет функций согласования транспортных протоколов. Поэтому для его работы с клиентами NetWare необходимо наличие на сервере компоненты NWLink или другого продукта, реализующего протокол Novell IPX.

Проблему организации межсетевого взаимодействия принято подразделять на две относительно независимые задачи: согласование транспортных подсистем (internetworking) и согласование высокоуровневых сервисов (interoperability).

8.4. Направление согласования

В то время как на трех нижних уровнях модели OSI протоколы почти всегда симметричны по отношению к взаимодействующим компьютерам, протоколы прикладного уровня, как правило, несимметричны и состоят из клиентской части, запрашивающей и потребляющей удаленный ресурс, и серверной части, предоставляющей этот ресурс в общее пользование. Клиентскую часть протокола часто называют редиректором или инициатором запросов.

При организации взаимодействия двух разнородных сетей в общем случае нужно решать две задачи - обеспечение доступа клиентов сети А к серверам сети В, и обеспечение доступа клиентов сети В к серверам сети А. Эти задачи независимы, и их можно решать отдельно. При выборе продуктов межсетевого взаимодействия прежде всего нужно выяснить, необходимо ли полное решение или достаточно и частичного.

Большинство имеющихся на рынке продуктов обеспечивает только однонаправленное согласование прикладных сервисов. Например, шлюз Gateway Services for NetWare обеспечивает клиентам Windows NT доступ к файл- и принт-сервисам NetWare, но не предоставляет клиентам NetWare доступ к аналогичным сервисам Windows NT. Обратная задача может быть решена с помощью продукта File and Print Services for NetWare, устанавливаемого на серверах Windows NT. Он представляет собой серверную часть протокола NCP, которая в режиме мультиплексирования работает параллельно с серверной частью "родного" для Windows NT протокола SMB.

8.5. Место размещения продуктов межсетевого взаимодействия

Если в качестве средства межсетевого взаимодействия выбран шлюз, то, как правило, он располагается на сервере той сети, в которой находятся его клиенты. Например, шлюз SNA Server, позволяющий клиентам Windows NT обращаться к мейнфреймам IBM, должен быть установлен на сервере Windows NT Server.

При использовании мультиплексоров протоколов существует два варианта размещения дополнительного стека протоколов - на одном или на другом взаимодействующем компьютере. Для протоколов типа "клиент-сервер" важно учитывать функциональные различия между клиентскими и серверными частями. Если дополнительный стек устанавливается на сервере, то этот сервер становится доступным для всех клиентов с этим стеком. При этом нужно тщательно оценивать влияние установки дополнительного продукта на производительность сервера.

При размещении дополнительного стека на клиентах вопросы производительности не так важны. Здесь более важными являются ограничения ресурсов клиентских машин, а также затраты труда администратора на установку и поддержание дополнительных стеков в работоспособном состоянии на большом числе компьютеров.

При выборе места размещения часто возникает и другой, чисто практический вопрос: имеется ли возможность изменять программное обеспечение обоих взаимодействующих сетей, или одна из них является недоступной? В принципе можно решить задачу взаимодействия двух сетей в полном объеме за счет установки согласующих продуктов только в одной сети - если для нее есть соответствующие продукты. Например, Windows NT позволяет обеспечить двустороннее взаимодействие с сетями NetWare, устанавливая дополнительные продукты только на своей стороне, оставляя в неизменном виде программное обеспечение клиентов и серверов NetWare. Клиенты на базе Windows NT Workstation получают доступ к сети NetWare с помощью установленных в них продуктов NWLink и NWCS, а серверы Windows NT Server предоставляют свои ресурсы клиентам сети NetWare с помощью продукта File and Print Services for NetWare. (Правда, нужно учитывать, что редиректор NWCS, поставляемый в версии 3.5х не поддерживает службу каталогов NDS компании Novell, поэтому для работы с серверами Net-Ware 4.x в качестве полноценных клиентов или тем более администраторов, следует использовать либо клиентов для NetWare, включенных в Windows NT 4.0, либо продукт компании Novell - NetWare Client for Windows NT.)

8.6. Реализация мультиплексирования протоколов в Windows NT

Windows NT представляет собой хороший пример операционной системы, мультиплексирующей несколько стеков протоколов - NetBEUI/SMB, TCP/IP и Novell IPX/NCP (компонента NWLink реализует протокол сетевого уровня IPX, а NWCS - протокол NCP, обеспечивающий доступ к файлам и принтерам).

Мультиплексирование может осуществляться на каждом из трех уровней коммуникационных средств: на нижнем уровне драйверов сетевых адаптеров, на уровне сетевых протоколов и на прикладном уровне (рисунок 8.1).

Рис. 8.1. Мультиплексирование в Windows NT

Для того, чтобы один сетевой протокол мог использовать несколько канальных протоколов (реализованных в виде драйверов сетевых адаптеров) и наоборот - один драйвер сетевого адаптера мог работать с несколькими сетевыми протоколами, в Windows NT на нижнем уровне используется мультиплексор NDIS (Network Driver Interface Specification), новая 32-разрядная версия 3.0 которого была разработана специально для Windows NT. NDIS выполняет не только функции мультиплексора, но и функции программной среды, изолирующей драйвер сетевого адаптера от аппаратуры, то есть от самого сетевого адаптера. NDIS предоставляет разработчику драйвера функции управления сетевым адаптером, например, функции ввода-вывода или обработки прерываний, что делает код драйвера более мобильным и переносимым. Windows NT поддерживает драйверы сетевых адаптеров не только в стандарте NDIS, но и в популярном стандарте ODI, используемом в сетях Novell NetWare.

На среднем уровне Windows NT вводит свой стандарт на интерфейс транспортных протоколов - TDI (Transport Driver Interface). Слово Driver говорит о том, что в Windows NT эти протоколы реализованы в виде драйверов системы ввода-вывода. Если редиректоры и транспортные протоколы написаны в соответствии с правилами TDI, то они могут образовывать произвольные связи между собой, то есть мультиплексироваться. Разработчикам приложений для доступа к функциям транспортного уровня Windows NT предлагает два популярных API - NetBIOS и Windows Sockets, которые в свою очередь обращаются к транспортным протоколам через интерфейс TDI.

Кроме собственных отдельных драйверов, разработанных в стандарте TDI (например, NetBEUI), Windows NT использует также модифицированную среду STREAMS, созданную в свое время знаменитым Денисом Ритчи для операционной системы Unix. Изменения среды STREAMS заключались в согласовании ее верхнего уровня с интерфейсом TDI. Это позволило использовать в Windows NT значительную часть кодов уже разработанных транспортных протоколов для этой среды.

На верхнем уровне в Windows NT имеется два мультиплексора - MUP и MPR, соответствующие двум сценариям доступа приложений к сетевым ресурсам в гетерогенной сети.

Первый сценарий состоит в том, что приложение обращается к операционной системе с запросом, указывая в явном виде имя сетевого ресурса без предварительного установления соединения. Такой запрос может быть выполнен при условии, что имя задано в соответствии с универсальным соглашением о именовании UNC (Universal Naming Convention).

В имени UNC сначала указывается имя сервера, предваряемое двумя слэшами, а затем сетевое имя разделяемого каталога и составное имя файла. Например, приложение может открыть файл, используя имя \\tandem\C$\Ann\article.doc, где tandem - имя компьютера, C$ - сетевое имя разделяемого каталога, назначенное пользователем или системой, \Ann\article.doc - составное имя файла относительно каталога C$.

Когда подсистема ввода-вывода Windows NT анализирует имя файла и обнаруживает, что оно является UNC-именем, то вызывается MUP (Multiple UNC Provider), которому передается это имя для дальнейшей обработки. В обязанности MUP входит определение принадлежности сетевого ресурса с заданным именем той или иной сети, инсталлированной в системе. Если обращение по этому имени происходит впервые, то MUP просто передает данное имя для опознания всем редиректорам, которые установлены в системе (их список имеется в базе конфигурации системы Registry). Каждый редиректор в соответствии с поддерживаемым им протоколом производит поиск ресурса по заданному имени и возвращает результат поиска мультиплексору MUP. MUP анализирует ответы редиректоров, и, если один из них распознал ресурс, передает ему запрос приложения для выполнения. Одновременно MUP кэширует соответствие имени сетевого ресурса определенному редиректору, чтобы не выполнять описанную процедуру каждый раз при поступлении запроса к этому ресурсу.

Реализован MUP в виде драйвера, в чем можно убедиться, просматривая список имен драйверов в группе Devices утилиты Control Panel.

В соответствии со вторым сценарием доступа приложение предварительно отображает сетевой ресурс на локальный ресурс (устанавливает соединение), а затем обращается к нему как к локальному ресурсу. Например, сначала разделяемый каталог \\tandem\C$ отображается на локальный дисковод F:, а затем приложение обращается к файлу F:\Ann\article.doc как к локальному файлу.

Процедура установления соединения в общем случае состоит из двух этапов:

• просмотр пользователем разделяемых сетевых ресурсов и выбор нужного ресурса,
• отображение выбранного ресурса на локальный ресурс.

Просмотр сетевых ресурсов - это необязательный этап, но он может существенно облегчить жизнь пользователю в большой сети, так как в этом случае пользователь не должен помнить имена всех серверов и разделяемых каталогов. В различных сетях сервис просмотра ресурсов организован по-разному. В сетях Novell NetWare 3.x, например, редиректор собирает список доступных серверов с помощью широковещательного протокола SAP, а в сетях NetWare 4.x редиректор для этой цели обращается с запросами к централизованной справочной службе NDS. В сетях Microsoft Windows NT список доступных серверов предоставляет специальная компонента - Computer Browser, а список разделяемых каталогов выясняется в результате диалога редиректора и сервера по протоколу SMB. В сетях TCP/IP при использовании сервисов ftp, telnet или www услуга по просмотру сетевых ресурсов вообще не предусмотрена, и пользователь должен явно задавать символьные имена ftp- или www-хостов, на которых хранятся нужные ему данные.

Процедуры просмотра ресурсов и установления соединения выполняются в Windows NT с участием еще одного мультиплексора прикладного уровня - маршрутизатора поставщиков услуг MPR (Multiple Provider Router). MPR, реализованный в виде динамической библиотеки DLL, выполняет общие для всех типов сетей действий по просмотру и отображению сетевых ресурсов в одном стиле. Действительно, пользователь видит, что в диалоговом окне Connect Network Drive утилиты File Manager перечень поддерживаемых сетей, набор имеющихся в них серверов и список разделяемых каталогов на серверах отображаются с помощью одних и тех же графических иконок, независимо от того, сеть ли это NetWare или Microsoft Windows. Другим примером может служить процедура дополнительной аутентификации при подключении к новой сети - она может быть выполнена одинаковым образом для сетей разных типов.

Другой основной функцией MPR является мультиплексирование связей между приложением и несколькими редиректорами. Если приложение не делает запрос на доступ к сетевому ресурсу в явном виде по UNC имени, а хочет сначала просмотреть и/или отобразить ресурсы, то такой запрос попадает сначала в MPR, который переправляет его нужному редиректору. Запросы от приложений могут явно указывать, с каким типом сети нужно работать - в этом случае MPR просто передает запрос указанному редиректору. Если же в запросе тип сети не указан, то MPR поступает так же, как и MUP - он передает запрос для опознания ресурса всем редиректорам и ждет от них ответы.

MPR взаимодействует с редиректорами не непосредственно, а через промежуточные компоненты, называемые сетевыми поставщиками услуг (network provider). Эти промежуточные компоненты обеспечивают согласование исходного интерфейса каждого редиректора с единым стандартным интерфейсом, с помощью которого MPR общается с редиректорами. Таким образом, для включения в Windows NT нового типа сети нужно разработать две компоненты - редиректор и сетевой поставщик услуг.

Разделение обязанностей между сетевым поставщиком услуг и редиректором - их внутреннее дело, главное, чтобы поставщик поддерживал стандартный интерфейс с MPR. Встроенный поставщик сети Microsoft для получения списка доменов, рабочих групп и компьютеров обращается к сервису Computer Browser, а список разделяемых каталогов на сервере получает с помощью редиректора. При отображении разделяемого каталога на локальный дисковод, например, \\tandem\C$ на F:, поставщик услуг сам создает в дереве имен объектов Windows NT новый объект - символьную связь с именем F:, которая указывает на редиректор сети Microsoft. После создания такой связи работа мультиплексора MPR по поддержанию доступа к файлам (и подкаталогам) каталога F:\ закончена. Теперь эти обращения будут обрабатываться системой ввода-вывода Windows NT, которая, разбирая имя файла, обнаружит, что диск F: - это не реальное устройство, а символьная связь, и вызовет для дальнейшей обработки указанный в символьной связи нужный редиректор.

Назад | Содержание | Вперед