tanenbaum_seti_all.pages (525408), страница 14
Текст из файла (страница 14)
1 Л 3. Шесть типов служб Концепция использования ненадежной связи поначалу может показаться несколько странной. В самом деле, почему зто может возникать такая ситуация, когда выгоднее предпочесть ненадежную связь надежной? Во-первых, надежное соединение (в том смысле, который был оговорен ранее, то есть с подтверждением) не всегда можно установить. Скажем, Е1Ьегпег не является «надежным» средством коммуникации.
Пакеты при передаче могут искажаться, но решать эту проблему должны протоколы более высоких уровней. Во-вторых, задержки, связанные с отсылкой подтверждения, в некоторых случаях неприемлемы, особенно при передаче мультимедиа в реальном времени. Именно благодаря этим факторам продолжают сосуществовать надежные и ненадежные соединения. Примитивы служб Служба (сервис) формально описывается набором примитивов или операций, доступных пользователю или другой сушности для получения сервиса.
Эти примитивы заставляют службу выполнять некоторые действия или служат ответами на действия сущности того же уровня. Если набор протоколов входит в состав операционной системы (как часто и бывает), то примитивы являются системными вызовами. Они приводят к возникновению системных прерываний в привилегированном режиме, в результате чего управление машиной передается операционной системе, которая и отсылает нужные пакеты. Набор доступных прилгитивов зависит от природы сервиса.
Скажем, примитивы сервисов с установлением соединения и без него различаются. В табл. 1.3 приведен минимальный набор примитивов, обеспечнваюший надежную передачу битового потока в среде типа «клиент-сервер». Эти примитивы могут использоваться следуюшим образом. Вначале сервер исполняет 1.1БТЕХ, показывая тем самым, что он готов устанавливать входящие соединения.
Этот примитив обычно реализуется в виде блокирующего системного вызова. После его исполнения процесс сервера приостанавливается до тех пор, пока не будет установлено соединение. Сетевое программное обеспечение 59 Таблица 1.3. Пять сервисных примитивов, обеспечивающих простую передачу с установлением соединения Значение Примитив Блок ожидает входящего соединения Установка соединения с ожидающей сущностью того же ранга Блок ожидает входящего сообщения Отправка сообщения ожидающей сущности того же ранга Разрыв соединения ОБТЕМ (ожидание) ССММЕСТ (соединение) БЕСЕ)ЧЕ (прием) БЕМС (отправка) 0(БСОМ МЕСТ (разрыв) Клиент Сервер ни Процесс имеет И $ в Рис.
1.14. Простейшее взаимодействие клиента и сервера лри передаче пакетов по сети с установлением соединения Самым очевидным жизненным примером такого взаимодействия может служить звонок покупателя (клиента) в сервисный центр компании. Менеджер сер- Затем процесс клиента выполняет примитив СОХ'.чЕСТ, устанавливая соединение с сервером. В системном вызове должно быть указано, с кем именно необходимо установить связь. Для этого может вводиться специальный параметр, содержащий адрес сервера. Далее операционная система клиента посылает равноранговой сушности пакет с запросом на соединение, как показано на рис.
1.14 стрелочкой с пометкой (1). Процесс клиента приостанавливается в ожидании ответа. Пакет, пришедший на сервер, обрабатывается его операционной системой. Если в пакете обнаруживается запрос на соединение, начинается поиск того клиента, который отправил этот запрос. При его обнаружении производятся два действия: клиент разблокируется и ему отсылается подтверждение (2). Реальное разблокирование происходит по прибытии подтверждения па клиентскую машину. Начиная с этого момента считается, что сервер и клиент установили соединение. Важно отметить здесь то, что подтверждение (2) генерируется самим кодом протокола и не является ответом на примитив пользователя, содержащий запрос. Может возникнуть ситуация, когда запрос на соединение есть, а клиента нет. В этом случае результат будет неопределенным.
В некоторых системах пакет может быть отложен на короткое время, в течение которого ожидается Е15ТЕХ. 60 Глава 1. Введение висного центра должен нахолиться у телефона, чтобы иметь возможность ответить в том случае, если он зазвонит. Клиент совершает звонок.
Когда менеджер поднимает трубку, считается, что соединение установлено. Следующим шагом будет вьпюлнение сервером примитива КЕСЕ1ЧЕ, подготавливающего систему к принятию первого запроса. В нормальной ситуации это происходит сразу же после прекращения ожидания (Е1ЯТЕХ), даже до того, как клиент получает подтверждение соединения. Системный вызов КЕСЕ1ЧЕ вновь блокирует сервер. Клиент выполняет 5ЕХР, передаст запрос (3) и сразу же вьпюлняет КЕСЕ1ЧЕ, ожидая ответ. Прием пакета с запросом разблокирует процесс сервера, благодаря чему он может обработать запрос.
По окончании обработки выполняется примитив 5ЕХР, и ответ отсылается клиенту (4). Прием пакета разблокирует клиента, теперь наступает его очередь обрабатывать пакет. Если у клиента есть еще запросы к серверу, он может отослать их. В противном случае соединение разрывается с помощью Р15СОХХЕСТ.
Обычно первый примитив Р1ЯСОХХЕСТ отсылает пакет, уведомляющий сервер об окончании сеанса, и блокирует клиента (5). В ответ сервер генерирует свой примитив Р1ЯСОХХЕСТ, являющийся подтверждением для клиента и командой, разрывающей связь. Клиент, получив его, разблокируется, и соединение считается окончательно разорванным. Именно так в двух словах можно описать схему коммуникации с установлением соединения, Конечно, жизнь не настолько проста.
Описанный алгоритм работы весьма схематичен, а кое-что просто неправильно (например, СОХХЕСТ на самом деле выполняется до ЫЕТЕХ). При этом пакеты, бывает, теряются, возникают и другие проблемы. Позднее мы рассмотрим все это гораздо более подробно, но па данный момент можно получить лишь общее представление о работе клиент-серверной системы с установлением соединения.
Для этого полезно внимательно изучить рис. 1.14. Увидев эти шесть пакетов, необходимых для работы протокола, можно удивиться, почему же пе используется протокол без установления соединения? Ответ таков: в идеальном мире, где нужны всего два пакета — один для запроса и один для ответа, — это, возможно, имело бы смысл. Но стоит представить себе передачу большого сообщения (скажсм, мегабайтного файла), причем в обе стороны, причем с ошибками при передаче, потерянными пакетами и т.
д., как ситуация меняется. Если ответ сервера состоит из нескольких сотен пакетов, парочка из которых затерялась по пути, то как клиент узнает, что он получил сообщение не в полном объеме? Как он узнает о том, что последний принятый пакет является действительно последним? Допустим, клиент запросил второй файл. Как он отличит пакет 1 из второго файла от потерянного пакета 1 из первого файла, который вдруг нашелся? Короче говоря, в реальном мире простой протокол запросов-ответов без подтверждений часто не подходит.
В главе 3 мы обсудим протоколы, позволяющие решать самые разные проблемы, возникающие при передаче данных. А сейчас поверьте на слово: наличие надежной связи с упорядоченным байтовым потоком между процессами — это удобно. Сетевое программное обеспечение 61 Службы и протоколы Службы и протоколы являются различными понятиями, хотя часто этн понятия смешиваются. Различие между ниии, однако, столь важно, что мы хотели бы сшс раз обратить на него наше внимание. Служба (или сервис) — это набор примитивов (операций), которые более низкий уровень предоставляет более высокому. Служба опрсдсляст, какие именно операции уровень будет выполнять от лица своих пользоватслей, цо никак нс оговаривает, как должны реализовываться эти опсрации.
Служба описывает интерфейс между двумя уровнями, в котором нижний уровень является поставщиком сервиса, а верхний — его потребителем. Напротив, протокол — это набор правил, описывающих формат и назначение кадров, пакетов или сообщений, которыми обмениваются одноранговые сущности внутри уровня. Сушпости используют протокол для реализации определений их служб.
Оии могут менять протокол по желанию, при условии что при этом остаются неизменными службы, предоставляемые ими своим пользователям. Таким образом, служба и протокол оказываются практически независимыми. Другими словами, службы — это почто связанное с мсжуровнслыми интерфейсами, тогда как протоколы связаны с пакетами, псрсдающимися сущностями одного уровня, расположснпыми иа разных машинах. Это показано па рис. Б15. Важно ис путать эти лва понятия. Стоит провести аналогию с языками программирования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
