13. Примитивы служб

Служба (сервис) формально описывается набором примитивов или операций, доступных пользователю или другой сущности для получения сервиса. Эти примитивы заставляют службу выполнять некоторые действия или служат ответами на действия сущности того же уровня. Если набор протоколов входит в состав операционной системы (как часто и бывает), то примитивы являются системными вызовами. Они приводят к возникновению системных прерываний в привилегированном режиме, в результате чего управление машиной передается операци­онной системе, которая и отсылает нужные пакеты.

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

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

Таблица 1.3. Пять сервисных примитивов, обеспечивающих простую передачу с установлением соединения

Примитив	Значение
LISTEN (ожидание)	Блок ожидает входящего соединения
CONNECT (соединение)	Установка соединения с ожидающей сущностью того же ранга
RECEIVE (прием)	Блок ожидает входящего сообщения
SEND (отправка)	Отправка сообщения ожидающей сущности того же ранга
DISCONNECT (разрыв)	Разрыв соединения

Затем процесс клиента выполняет примитив CONNECT, устанавливая соединение с сервером. В системном вызове должно быть указано, с кем именно необходимо установить связь. Для этого может вводиться специальный параметр, содержащий адрес сервера. Далее операционная система клиента посылает равноранговой сущности пакет с запросом на соединение, как показано на рис. 1.14 стрелочкой с пометкой (1). Процесс клиента приостанавливается в ожидании ответа. Пакет, пришедший на сервер, обрабатывается его операционной системой. Если в пакете обнаруживается запрос на соединение, начинается поиск того кли­ента, который отправил этот запрос. При его обнаружении производятся два дей­ствия: клиент разблокируется и ему отсылается подтверждение (2). Реальное разблокирование происходит по прибытии подтверждения на клиентскую машину. Начиная с этого момента считается, что сервер и клиент установили соединение. Важно отметить здесь то, что подтверждение (2) генерируется самим кодом протокола и не является ответом на примитив пользователя, содержащий запрос. Может возникнуть ситуация, когда запрос на соединение есть, а клиента нет. В этом случае результат будет неопределенным. В некоторых системах пакет может быть отложен на короткое время, в течение которого ожидается LISTEN.

Рис. 1.14. Простейшее взаимодействие клиента и сервера при передаче пакетов по сети с установлением соединения

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

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

Клиент выполняет SEND, передает запрос (3) и сразу же выполняет RECEIVE, ожидая ответ.

Прием пакета с запросом разблокирует процесс сервера, благодаря чему он может обработать запрос. По окончании обработки выполняется примитив SEND, и ответ отсылается клиенту (4). Прием пакета разблокирует клиента, теперь наступает его очередь обрабатывать пакет. Если у клиента есть еще запросы к серверу, он может отослать их. В противном случае соединение разрывается с помощью DISCONNECT. Обычно первый примитив DISCONNECT отсылает пакет, уведомляющий сервер об окончании сеанса, и блокирует клиента (5). В ответ сервер генерирует свой примитив DISCONNECT, являющийся подтверждением для клиента и командой, разрывающей связь. Клиент, получив его, разблокируется, и соединение считается окончательно разорванным. Именно так в двух словах можно описать схему коммуникации с установлением соединения.

Конечно, жизнь не настолько проста. Описанный алгоритм работы весьма схематичен, а коечто просто неправильно (например, CONNECT на самом деле выполняется до LISTEN). При этом пакеты, бывает, теряются, возникают и другие проблемы. Позднее мы рассмотрим все это гораздо более подробно, но на данный момент можно получить лишь общее представление о работе клиентсерверной системы с установлением соединения. Для этого полезно внимательно изучить рис. 1.14.

Увидев эти шесть пакетов, необходимых для работы протокола, можно удивиться, почему же не используется протокол без установления соединения? Ответ таков: в идеальном мире, где нужны всего два пакета – один для запроса и один для ответа, – это, возможно, имело бы смысл. Но стоит представить себе передачу большого сообщения (скажем, мегабайтного файла), причем в обе стороны, причем с ошибками при передаче, потерянными пакетами и т. д., как ситуация меняется. Если ответ сервера состоит из нескольких сотен пакетов, парочка из которых затерялась по пути, то как клиент узнает, что он получил сообщение не в полном объеме? Как он узнает о том, что последний принятый пакет является действительно последним? Допустим, клиент запросил второй файл. Как он отличит пакет 1 из второго файла от потерянного пакета 1 из первого файла, который вдруг нашелся? Короче говоря, в реальном мире простой протокол запрос-ответов без подтверждений часто не подходит. Далее мы обсудим протоколы, позволяющие решать самые разные проблемы, возникающие при передаче данных. А сейчас поверьте на слово: наличие надежной связи с упорядоченным байтовым потоком между процессами – это удобно