6.3 Основные сетевые интерфейсы

Для передачи данных прикладного уровня транспортному используют различные интерфейсы. Например,

• Сокеты

• TLI

• RPC

1. Впервые интерфейс сокетов был реализован для BSD Unix.

Механизм сокетов предоставляет интерфейс обмена сообщениями, предназначенный для разработки сетевых распределенных приложений.

Концепции:

• независимость от нижележащих сетевых протоколов и технологий

• использование абстрактной точки соединения – сокета

• именование сокета может быть как высокоуровневое символьное, так низкоуровневое IP

• могут существовать Сокеты различных типов для разных типов коммуникационных доменов (дейтаграммные для UDP и потоковые для TCP)

• для обмена сообщениями поддерживается набор примитивов, реализованный как системные вызовы. (soket- создание, bind- связывание, connect- установление соединения, listen- прослушивание и т.д.)

Взаимодействие носит клиент-серверный характер. Сокет-сервер ждет акивизации сокета-клиента.

Прежде чем начать передачу, Сокеты должны договориться о протоколе передачи и номере порта. Если это TCP устанавливается предварительное соединение (физический канал). При UDP соединение не устанавливается (логический канал). Задача протокола транспортного уровня найти коммуникационный узел, через который пойдет передача.

2. Механизм вызова удаленных процедур представляет собой надстройку над системой обмена сообщениями и в ряде случаев оказывается более удобным для взаимодействия программ.

Концепция:

• это расширение механизма передачи управления и данных внутри программы.

• наибольшая эффективность достигается для интерактивных приложений

• характеризуется ассиметричностью – одна из взаимодействующих сторон является инициатором взаимодействия

• характеризуется синхронностью – выполнение вызывающей процедуры блокируется с момента выдачи запроса и возобновляется только после возврата из вызывающей процедуры

3. TLI (Transport Layer Interfase) реализован в SystemV и основан на архитектуре STREAMS.

Концепции:

• предоставляет набор вызовов, предназначенных для сетевых приложений. Для преобразования вызовов в функции STREAMS используется библиотека TLI.

• схема использования похожа на интерфейс сокетов и основана на использовании протоколов транспортного уровня (например, TCP или UDP).

• архитектура интерфейса основана на модели OSI (поэтому не оптимальна)

• можно использовать с протоколами IPX/SPX под NOVELL

Интерфейс TLI получил развитие в виде интерфейса XTI (X/Open Transport Interfase)

Вывод: в обычных ситуациях нет смысла использовать XTLI/TLI/ Интерфейс сокетов проще, а возможности почти одинаковые.

6.4 Доступ к сетевым ресурсам

NFS (Сетевая Файловая Система)

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

Существуют несколько решений - сетевые файловые системы NFS (Network File System - сетевая файловая система) разработана компанией Sun Microsystems ветвь BSD и RFS (Remote File Sharing - совместное использование удаленных файлов) реализована компанией AT&T ветвь SystemV.

Основным недостатком RFS является то, что реализация RFS основана на использовании интерфейса TLI и система реализуема только на компьютерах, работающих под управлением ОС UNIX. Недостаток NFS в том, что ее можно использовать только в TCP/IP-ориентированных сетях.

В архитектурном отношении в NFS выделяются три основные части:

1. протокол,

2. серверная часть

3. клиентская часть.

Протокол NFS опирается на примитивы RPC.

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

NFS поддерживает разнород­ные системы, в которых клиенты и серверы могут работать под управлением раз­личных операционных систем и на различном оборудовании.

В файловой системе NFS задача определения интерфейсов между клиентом и сервером выполняется при помощи двух протоко­лов.

Работой NFS управляют два демона nfsd(8) и mountd(8). Mountd выполняет функции сервера, a nfsd выполняет функции клиента. Он готовит запрос, связанный с монтированием удаленной ф/с и передает его на удаленный узел (на котором на этот запрос отвечает демон mountd).

Для NFS разработаны два протокола.

Первый протокол NFS управляет монтированием каталогов.

Монтирование может быть

1. статическим. Тогда команды монтировки файловых систем размещаются в файле /etc/rc (тип файловой системы указывается nfs. Имя файловой системы состоит из имени хоста и имени каталога, в котором она размещена). Таким образом, все необходимые удаленные файловые системы будут автоматически смонтированы прежде, чем будет разрешена регистрация в системе.

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

В этом случае используются два файла: на клиенте в файлe /etc/fstab(таблица автомонтирования), который содержит инструкции о том, какие ф/с надо монтировать при запуске и в какое место, а на сервере в файле /etc/exports указываются экспортируемые деревья файловой системы клиенту.

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

Запуск серверов

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

1. вручную из командной строки, введя имя программы-сервера с аргументами.

2. автоматически при запуске системы. В этом случае возможны два варианта:

2.1 сервер работает непрерывно с момента запуска. Это удобно в том случае, когда сервер используется часто.

2.2 запускается только при получении запроса от клиента

Для автоматического запуска сервера при запуске системы, используют сценарий запуска /etc/rc.d/init.d. Если сервер будет запускаться по требованию, надо сконфигурировать запуск сервера демоном inetd. Для этого делается соответствующая запись в файлах inetd.conf и /etc/services.

Демон inetd ожидает поступления на сервер запросов и запускает его только, когда потребуются услуги сервера.

Протокол FTP

FTP расшифровывается, как File Transfer Protocol (протокол передачи файлов). Он позволяет вам отсылать и принимать файлы между двумя компьютерами. Один из них FTP сервер, а другой - FTP клиент.

Работает на TCP/IP. Пользователь FTP может вызывать несколько команд, которые позволяют ему посмотреть каталог удаленной машины, перейти из одного каталога в другой, а также скопировать один или несколько файлов.

Для конфигурации запуска по требованию надо в файле /etc/services указать название потока и соответствующий ему номер порта

ftp-data 20/tcp

ftp 21/tcp

А в файле inetd.conf надо указать сетевую службу, ее протокол и вызываемую серверную программу.

# <service> <Sock_type> <proto> <flags> <user> <server_path> <args>

ftp stream tcp nowait root /usr/sbin/ftpd ftpd

Основные компоненты:

Сервер-FTP состоит из интерпретатора команд, процесса передачи данных.

Клиент-FTP состоит из пользовательского интерфейса, интерпретатора команд и процесса передачи данных.

Управляющее соединение: TCP-соединение между интерпретаторами команд сервера и клиента на базе протокола Telnet. Клиент посылает по нему команды; сервер - ответы. Сервер слушает на порту 21 (по умолчанию); клиент инициирует соединение – порт 20. Закрывается сервером по команде клиента.

Кроме протокола ftp, есть протокол tftp (trivial ftp), основанный на UDP.

Протокол SMB

Протокол SMB (Server Message Block)– один из методов использования файлов в Windows. SMB – это протокол, определяющий структуру данных при передаче. Он формируется вокруг интерфейса NetBIOS.

SMB проверяет права доступа пользователя, а не системы как это делается в NFS. Поэтому предназначена для использования на PC, практически не оснащенных элементами локальной защиты. Защита реализована на уровне сервера.

Одно из преимуществ SMB для Unix – это интеграция компьютера Unix и стандартного приложения Network Neighborhood (сетевое окружение) сети Windows. При наличии NFS в Widows отображаются две сети: Windows и NFS, что требует большего объема работы со стороны пользователя для отслеживания сетевого ресурса. При наличии SMB в Unix пользователь не сможет отличить компьютер Unix от компьютера Windows в окне Network Neighborhood.

Пример программного решения для SMB – свободно распространяемое обеспечение SAMBA.

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

1. настроить компьютер Windows (присвоить IP адрес серверу, назначить имя компьютера и рабочей группы, поместить эти данные в файл C:\Windows\hosts)/

2. Настроить компьютер Linux (подготовить каталоги, применяемые в качестве сетевого ресурса, дописать в файлы /etc/samba/lmhosts и /etc/hosts строки, содержащие адреса Win компьютеров)

3. Запустит демон smb.

Настраивать файловый сервер удобно с помощью службы swat (samba web administration tool).

CIFS

SMB в конечном счете уступит место CIFS (Common Internet File System). Файловая система CIFS – это расширенное определение SMB. CIFS не зависит от NetBIOS. Одним из больших преимуществ CIFS является то, что можно скопировать часть файла и не копировать весь. Если очень большой файл был размещен на удаленном компьютере, то система, совместимая со стандартом CIFS, может выдать запрос на специфическую часть файла (например, последнюю строку), вместо того, чтобы копировать весь

Технология тонких серверов

Тонкие серверы – это новая категория компьютерного аппаратного обеспечения, которая обеспечивает совместное использование данных посредством NFS и CIFS/SMB. Если возникает необходимость в дополнительной файловой памяти, то применение тонких серверов может быть решением этой проблемы.

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

• они поддерживают как методы SMB, так и методы NFS для совместного использования файлов, так что для клиента или сервера не требуется дополнительное программное обеспечение

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

Тонкие серверы имеют от 25 до 40 команд, которые содержатся в словаре их ОС. Поскольку тонкие серверы выполняют только одну функцию, то исключаются дополнительные затраты как дискового пространства, так и памяти для несвязанных задач.

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

Подключение к системе через сеть

r-команды

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

Существует целая серия "r-команд" (от remote - удаленный), которые впервые появились в ОС UNIX. Они являются аналогами обычных команд UNIX, но предназначены для работы с удаленными машинами. Например, команда rcp является аналогом команды cp и предназначена для копирования файлов между машинами. Для передачи файла на узел delta достаточно ввести

rcp file.c delta:

Для выполнения команды "cc file.c" на машине delta можно использовать команду rsh:

rsh delta cc file.c

Для организации входа в удаленную систему предназначена команда rlogin:

Существуют также и другие способы подключения к системе посредством сети. Например, telnet и rlogin - основные службы в TCP/IP сетях.

Протокол TELNET

Протокол TELNET позволяет вам войти в удалённую систему точно так же, как если бы вы сидели за этим компьютером. Указав ваше имя пользователя и пароль, вам выдаётся приглашение командной строки оболочки. С этого момента вы можете делать всё то же, что обычно выполняете в текстовой консоли.

TELNET работает на базе протокола TCP. На прикладном уровне над TELNET находится либо программа поддержки реального терминала (на стороне пользователя), либо прикладной процесс в обсуживающей машине, к которому осуществляется доступ с терминала.

Замечание: telnet не кодирует информацию, которую он посылает. Всё посылается, как обычный текст, даже пароли. Не желательно использовать telnet через интернет. Альтернатива – протокол ssh (Secure Shell). Она кодирует весь трафик и доступна бесплатно.

Команда talk

talk(1) позволяет пользователям переговариваться между собой при помощи текстовых сообщений. Экран разделяется горизонтально на две половины.

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

Доступ Unix в Unix

Система uucp позволяет связать несколько машин воедино и создать то, что в некоторых отношениях является виртуальным окружением, позволяющим вам работать на любой машине. Функционирование такой сети основано на удаленной регистрации в системе (cu(1)), дистанционном выполнении команд (uux(1)), электронной почте (mail(1)), передаче файлов (uucp(1), uucico(1)) и опознавании узла системы (uname(1) и uuname(1)).

Первый тип подключения - прямое подключение/ Вызывающая система использует последовательный порт для вывода, поэтому на этом порту не должно быть процесса getty. Инициирующая команда "cu -ltty00 -s9600 dir" обеспечивает подключение к последовательному порту tty00 на очень высокой скорости обмена. В вызываемой системе задействованы процессы getty, работающие со скоростью 9600 бод на входящей терминальной линии. Когда пользователь вводит регистрационное имя, getty выполняет процесс login, запрашивающий пароль, и если этот пароль верный, запускается shell.

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

Когда вы пересылаете файлы между машинами, uucp придерживается определенных протоколов и стандартов. Один из них связан с тем, откуда и куда могут поступать файлы. Чтобы свести возможную неразбериху к минимуму и обеспечить определенную степень защиты, создаются защищенный и публичный каталоги для хранения стоящих в очереди заданий и переданных файлов.

Когда удаленная система регистрируется в центральной системе с помощью uucp, несколько файлов в центральной системе определяют, какие возможности имеет удаленная система. Эти конфигурационные файлы размещаются в каталоге /usr/lib/uucp.