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

Рисунок 3.14 иллюстрирует принцип функционирования шлюза. В показанном примере шлюз, размещенный на компьютере 2, согласовывает протоколы клиентского компьютера 1 сети А с протоколами серверного компьютера 3 сети В. Допустим, что две сети используют   стеки протоколов , которые отличаются целиком Как очевидно из рисунка, в шлюзе реализованные оба стека протоколы.

Рис. 3.14.  Принципы функционирования шлюза

Запрос от прикладного процесса клиентского компьютера сети А поступает на прикладной уровень его стека протоколов. Согласно этому протоколу на прикладному уровне формируются соответствующий пакет (или несколько пакетов), в которых передается запрос на выполнение сервиса некоторому серверу сети В. Пакет прикладного уровня передается вниз по зтечу компьютера сети А, а потом согласно протоколам канального и физического уровней сети А поступает в компьютер 2, то есть в шлюз.

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

Мультиплексирование стеков протоколов

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

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

При мультиплексировании стеков протоколов на один из двух взаимодействующих компьютеров с разными стеками протоколов помещается коммуникационный стек другого компьютера. На рисунке 3.15 приведенный пример взаимодействия клиентского компьютера сети 1 с сервером своей сети и сервером сети 2, что работает со стеком протоколов, который целиком отличается от стека сети 1. В клиентском компьютере реализованные оба стека. Для того, чтобы запрос от прикладного процесса был правильно обработанный и направленный через соответствующий стек, в компьютер необходимо добавить специальный программный элемент - мультиплексор протоколов. Мультиплексор должен уметь определять, к какой сети направляется запрос клиента. Для этого может использоваться служба имен сети, в которой отмечается принадлежности того или другого ресурса определенной сети с соответствующим стеком протоколов.

При использовании технологии мультиплексирования структура коммуникационных средств операционной системы может быть и более сложной. В общем случае на каждом уровне вместо одного протокола появляется целый набор протоколов, а мультиплексоров может быть несколько, что выполняют коммутацию между протоколами разных уровней (рисунок 3.16). Например, рабочая станция может получить доступ к сетям с протоколами Netbios, IP, IPX через один сетевой адаптер. Аналогично, сервер, который поддерживает прикладные протоколы NCP, SMB и NFS может без проблем выполнять запросы рабочих станций сетей Netware, Windows NT и Sun одновременно.

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

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

 

Возможно стоит прочитать: