41. Транспортная служба. Сокеты Беркли.
Функции транспортного уровня состоят в установлении транспортного соединения между точками доступа, транспортировке данных по этому соединению, управлении потоком данных, исправлении ошибок транспортировки. Эти функции реализуются на трех разных этапах: этапе установления соединения, этапе переноса данных и этапе терминации соединения.
Сокеты Беркли
Теперь рассмотрим другой набор транспортных примитивов - примитивы сокетов (иногда называемых гнездами), используемые в операционной системе Berkeley UNIX для протокола ТСС (Transmission Control Protocol —протокол управления передачей). Они приведены в табл. 6.2. Модель сокетов во многом подобна рассмотренной ранее модели транспортных примитивов, но обладает большей гибкостью и предоставляет больше возможностей.
Первые четыре примитива списка выполняются серверами в таком же порядке. Примитив SOCKET создает новый сокет и выделяет для него место в таблице транспортной сущности. Параметры вызова yказывают используемый формат адресов, тип требуемой услуги (например, надежный байтовый поток) и протокол. B случае успеха примитив SOСКЕТ возвращает обычный описатель файла, используемого при вызове следующих примитивов, подобно тому, как возвращает описатель файла процедура OPEN.
У только что сознанного сокeта нет сетевых адресов. Они назначаются c помощью примитива BIND. После того как сервер привязывает адрес к сокету, c ним могут связаться удаленные клиенты. Вызов SОСКЕТ не создает адрес напрямую, так как некоторые процессы придают адресам большое значение (например, они использовали один и тот же адрес годами, и этот адрес всем известен), тогда как другим процессам это не важно.
Следом идет вызов LISTEN, который выделяет место для очереди входящих звонков на случай, если несколько клиентов пытаются соединиться одновременно. В отличие от примитива LISTEN в нашем первом примитиве, примитив LISTEN гнездовой модели не является блокирующим вызовом.
Чтобы заблокировать ожидание входящих соединений, сервер выполняет примитив АССЕРТ. Получив ТРDU-модyль c запросом соединения, транспортная сущность создает новый сокет с теми же свойствами , что и y исходного cокета, и возвращает описатель файла для него. При этом cервер может разветвить процесс или поток, чтобы обработать соединение для нового сокетa и вернуться к ожиданию следующего соединения для оригинального сокета.
Теперь посмотрим на этот процесс co стороны клиента. B этой случае также сначала с помощью примитива SOCKET должен быть создан сокет, но примитив BIND здесь не требуется, так как используемый адрес не имеет значения для сервера. Примитив CONNECT блокирует вызывающего и инициирует активный процесс соединения. Когда этот npoцеcc завершается (то есть когда соответствующий ТРDU модуль, посланный сервером, получен), процесс клиента разблокируется и соединение считается установленным. После этого обе стороны могут использовать примитивы SEND и RECV для передачи и получения данных по полнодуплексному соединению. Могут также применяться стандартные UNIX-вызовы READ и WRITE, если нет нужды в использовании специальных свойств SEND и RECV.
В модели сокетов используется симметричный разрыв соединения. Соединение разрывается, когда обе стороны выполняют примитив CLOSE.