On-Line Библиотека www.XServer.ru - учебники, книги, статьи, документация, нормативная литература.
       Главная         В избранное         Контакты        Карта сайта   
    Навигация XServer.ru








 

Интерфейсы

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

                       Интерфейс клиент/TCP                       
   Нижеприведенное функциональное описание команд клиента, посыла- 
емых программе протокола TCP, является, в лучшем случае, умозри- 
тельным, поскольку каждая операционная система будет иметь свои 
характеристики. Следовательно, мы должны предупредить читателей о 
том, что различные реализации протокола TCP могут иметь различный 
интерфейс с клиентом. Однако, все реализации протокола TCP должны 
обеспечивать некий минимальный набор услуг с тем, чтобы гарантиро- 
вать, что все они придерживаются единой иерархии протокола. Данная 
глава описывает функциональный интерфейс, обязательный для всех 
реализаций протокола TCP.

                        TCP команды клиента                       
   В следующих параграфах функционально характеризуется интерфейс 
клиент/протокол TCP. Нотация вызова подобна нотации большинства 
процедур или нотации вызова функции в языках высокого уровня, од- 
нако это не означает неправомерность вызовов на обслуживание в 
виде ловушек (trap) (например SVC, UUO, EMT).
   Описанные ниже команды клиента определяют основные операции, 
которые должна выполнять программа протокола TCP для поддержки 
коммуникаций между процессами. Отдельные реализации протокола дол- 
жны определять свой собственный конкретный формат и могут обеспе- 
чить комбинации или наборы базовых функций для одиночных вызовов. 
В частности, некоторые реализации могут автоматически открывать 
соединение (OPEN), как только по нему клиент дает первую команду 
посылки (SEND) или получения (RECEIVE). 
   Для того, чтобы поддерживать интерфейс между процессами, про- 
грамма TCP должна не только принимать команды, но и возвращать 
некую информацию обслуживаемым процессам. Эта информация состоит 
из:
a) общей информации о соединении (т.е. прерываний, закрытия соеди- 
   нения партнером, управление связью с непредопределенным чужим 
   сокетом).
b) ответа на конкретные команды клиента, указыващего на успешность 
   действий или различные типы ошибок.

Команда открытия
   Формат 
   OPEN (свой порт, чужой порт, активный/пассивный [,контрольное 
   время] [,приоритет] [,безопасность] [,опции]) -> местное имя 
   для соединения
      Мы полагаем, что местная программа TCP несет ответственность 
   за идентификацию обслуживаемых процессов и будет проверять при- 
   надлежность процессов, желающих обратиться к данному соедине- 
   нию. В зависимости от реализации протокола TCP, либо программа 
   TCP, либо протокол более нижнего уровня (например, IP) будут 
   создавать адрес отправителя, а точнее, идентификаторы для ло- 
   кальной сети и интерфейса TCP. Такая предусмотрительность явля- 
   ется результатом учета безопасности, а именно того, чтобы ни 
   одна из программ TCP не смогла замаскироваться под какую-либо 
   другую, и т.д. Аналогичным образом ни один процесс не должен 
   замаскироваться под другой без того, чтобы не иметь конфликт с 
   протоколом TCP.
      Если флаг активный/пассивный установлен в состояние 
   "пассивный", то это означает, что дан запрос на "прослушивание" 
   (LISTEN) сигнала установления соединения извне. Пассивное от- 
   крытие может дать либо полное описание чужого сокета, с которым 
   должно быть установлено данное соединение, либо не давать ника- 
   ких указаний по поводу чужого сокета, который должен дать сиг- 
   нал. Пассивное открытие соединения с четко определенным чужим 
   сокетом может стать в любой момент активным открытым соединени- 
   ем, если будет дана команда на посылку данных (SEND). Создается 
   блок управления передачей (TCB) и частично заполняется информа- 
   цией, полученной от параметров команды OPEN.
      В случае команды на активное открытие (OPEN) протокол TCP 
   немедленно запустит процедуру синхронизации (точнее, установле- 
   ния) соединения.
      Контрольное время, если оно присутствует среди параметров 
   функции, позволяет клиенту установить контрольное время ликви- 
   дации для всех данных, посылаемых от имени протокола TCP. Если 
   в течение этого контрольного времени какие-либо данные не до- 
   стигли своего адресата, программа TCP ликвидирует соединение. В 
   настоящее время общепринятым контрольным временем являются пять 
   минут.
      Программа протокола TCP или какая-либо компонента операцион- 
   ной системы будет проверять права клиента на открытие соедине- 
   ния, имеющего заказанные клиентом приоритет и безопасность. Ес- 
   ли приоритет или безопасность/закрытость не указаны, должен ис- 
   пользоваться вызов CALL, использующий значения этих параметров, 
   принятые по умолчанию. 
      Программа протокола TCP будет воспринимать приходящие запро- 
   сы только если они имеют тот же самый уровень безопасности/за- 
   крытости. Приоритет запросов должен быть равен или превышать 
   приоритет, указанный в команда открытия (OPEN).
      Если приоритет для соединения оказывается больше, чем значе- 
   ние, указанное в запросе CALL, то берется приоритет из пришед- 
   шего запроса и становится постоянной характеристикой соедине- 
   ния. Разработчики могут перепоручить клиентам ведение перегово- 
   ров по поводу установления приоритета соединения. Например, 
   клиент может указывать приоритет, который должен быть присвоен 
   соединению. В другом примере, любая попытка повысить приоритет 
   соединения должна получить санкцию клиента.
      По завершении операции протокол TCP возвращает клиенту мест- 
   ное название для открытого соединения. Впоследствии имя соеди- 
   нения может использоваться в качестве короткого обозначения для 
   соединения, идентифицируемого парой <местный сокет, чужой со- 
   кет>.

Команда на посылку данных
   Формат
   SEND (местное название соединения, адрес буфера, количество 
   байтов с данными, флаг проталкивания, флаг срочности 
   [контрольное время])
      Данная команда приводит к тому, что данные, содержащиеся в 
   указанном клиентом буфере, передаются на указанное соединение. 
   Если соединение не было к этому времени открытым, команда SEND 
   является ошибочной. Некоторые реализации протокола TCP могут 
   позволить клиентам начинать общение сразу с команды SEND. При 
   этом команда OPEN должна осуществляться автоматически. Если 
   процесс, давший команду на посылку, не уполномочен использовать 
   данное соединение, команда возвращает клиенту ошибку.
      Если установлен флаг проталкивания (PUSH), то данные должны 
   быть переданы по назначению с соответствующим сообщением, а бит 
   PUSH должен быть установлен на последний из созданных в буфере 
   TCP сегментов. Если флаг PUSH не выставлен, то имеющиеся данные 
   могут быть объединены с данными из посылаемых следом датаграмм. 
   Кроме того, хост-компьютер, посылающий данные, может получить 
   сообщение от шлюза об истечении контрольного времени.
      Если хост-компьютер, осуществляющий сборку фрагментов дата- 
   граммы, не может в отведенное для этого время завершить свою 
   работу из-за получения ошибочного фрагмента, то он выкидывает 
   датаграмму и может послать сообщение об превышении контрольного 
   времени. Этого сообщения не следует посылать вовсе, если не был 
   получен нулевой фрагмент датаграммы.
      От шлюза приходит сообщение с кодом 0 ,а от хост-компьютера 
   - сообщение с кодом 1.

               Формат сообщения о ошибках с параметрами           
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |     Код       |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   указатель   |               не используется                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet заголовок + 64 бита данных из исходной датаграммы    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Поля IP протокола:
   Адрес получателя
        Компьютерная сеть и адрес отправителя заносятся в дата- 
      грамму, возвращающую ошибку. Клиенты могут использовать ко- 
      манду STATUS для определения состояния соединения. В некото- 
      рых реализациях протокол TCP может оповещать клиента, когда 
      выходит на связь незаказанный сокет. 
         Если было указано контрольное время, то в этом соединении 
      его текущее значение, заданное клиентом, будет изменено. 
         В простейших реализациях команда SEND не предает управле- 
      ние обратно вызвавшей ее программе, пока не будет завершена 
      передача или пока не будет превышено контрольное время. Од- 
      нако, такой простой метод может приводить к блокировке (на- 
      пример, когда обе стороны на концах соединения пытаются 
      сперва выполнить команду SEND, а лишь потом - RECEIVE) и 
      плохим эксплуатационным характеристикам. Поэтому такой под- 
      ход не рекомендуется использовать. В более сложной реализа- 
      ции возврат из функции SEND осуществляется незамедлительно, 
      что позволяет процессу выполняться параллельно с вводом/вы- 
      водом в компьютерную сеть. И даже более того - позволяет вы- 
      полнять одновременно несколько команд SEND. Множественные 
      команды SEND обрабатываются по принципу "первый пришел - 
      первый обслужен", поэтому протокол TCP будет иметь очередь, 
      которая не может быть обслужена мгновенно.
         Косвенным образом мы предположили асинхронность интерфей- 
      са с клиентом, при которой команда SEND вызывает появление 
      особого рода сигнала или псевдо-прерывания изобслуживающей 
      программы TCP. Альтернатива состоит в немедленном возврате 
      из команды. Например, команды SEND могут возвращать немед- 
      ленно подтверждение от местной системы, даже если посланный 
      сегмент не получил подтверждения от чужой программы TCP. Мы 
      оптимистически относимся к возможному успеху этой операции. 
      Если мы ошибаемся, то соединение в любом случае будет разор- 
      вано по истечении контрольного времени. В реализациях прото- 
      кола TCP такого типа (синхронных) будет все равно оставаться 
      некоторые асинхронные сигналы, одноко они будут относиться к 
      самому соединению, а не к конкретным сегментам или буферам.
         Чтобы процесс мог различать сообщения об ошибках и успеш- 
      ное рапорты от различных команд SEND, может оказаться удоб- 
      ным возвращать в ответ на запрос SEND адрес буфера наряду с 
      кодированным ответом. Сигналы между клиентом и протоколом 
      TCP обсуждаются ниже и определяют ту информацию, которую 
      следует возвращать отправившему команду процессу.

Команда получения
   Формат
   RECEIVE (местное имя соединения, адрес буфера, счетчик байт) -> 
   счетчик байт, флаг срочности, флаг проталкивания
      Данная команда размещает получаемую информацию в буфере, 
   связанном с конкретным соединением. Если команде не предшеству- 
   ет команда OPEN или если процесс, осуществляющий вызов, не 
   уполномочен на использование данного соединения, то возвращает- 
   ся ошибка. 
      В простейшей реализации протокола управление не должно пере- 
   даваться осуществившей вызов программе до тех пор, пока либо не 
   будет заполнен буфер, либо не произойдет какая-либо ошибка. Од- 
   нако данная схема в значительной мере подвержена блокировкам. 
   Более сложная реализация могла бы позволить за раз выдвигать 
   несколько команд RECEIVE. Эти запросы будут выполняться по мере 
   поступления сегментов с данными. Такая стратегия позволяет уве- 
   личить пропускную способность за счет применения более развитой 
   схемы (возможно, асинхронной), а также оповещения программы о 
   том, что получен сигнал проталкивания PUSH или заполнен буфер.
      Если получено достаточное количество данных, чтобы заполнить 
   буфер до того, как получен сигнал проталкивания PUSH, то в от- 
   вет на RECEIVE не будет установлен флаг PUSH. Буфер будет со- 
   держать столько данных, насколько позволяет его емкость. Если 
   сигнал PUSH обнаружен до того, как буфер заполнился, то буфер 
   будет возвращен заполненным частично и с сигналом PUSH. 
      Если обнаружены срочные данные, то сразу же по их прибытии 
   клиент будет оповещен сигналом от программы протокола TCP. Кли- 
   ент, получающий данные, должен по этому сигналу перейти в 
   "срочный режим". Если флаг срочности URGENT установлен, то до- 
   полнительные срочные данные останутся неполученными. Если флаг 
   URGENT сброшен, то данный запрос на получение RECEIVE возвратит 
   все срочные данные и клиент может освободиться от "срочного ре- 
   жима". Заметим, что данные, следующие за указателем срочности 
   (несрочные данные) не могут быть доставлены к клиенту в одном и 
   том же буфере с предыдущими срочными данными, если сам клиент 
   не определил четко границу.
      Чтобы проводить различие между несколькими сделанными коман- 
   дами на получение RECEIVED и следить за заполнением буферов, 
   код, возвращаемый клиенту сопровождается как указателем на бу- 
   фер, так и количеством действительно полученных данных.
      Другие реализации команды RECEIVE могут сами выделять буфер 
   для размещения получаемых данных или же программа протокола TCP 
   может одновременно с клиентом пользоваться циклическим буфером.

Команда закрытия соединения
   Формат
   CLOSE (локальное имя соединения)
      Данная команда приводит к закрытию указанного соединения. 
   Если соединение не открыто или отдавший команду процесс не 
   уполномочен использовать данное соединение, то возвращается со- 
   общение об ошибке. Предполагается, что закрытие соединения бу- 
   дет медлительной операцией в том смысле, что оставшиеся команды 
   посылки SEND будут еще некоторое время передавать данные (и да- 
   же, в случае необходимости, делать это повторно), насколько это 
   позволит управление потоком, и не будет выполнена заказанная 
   работа. Таким образом, можно будет сделать несколько команд по- 
   сылки SEND, а затем закрыть соединение командой CLOSE, будучи 
   уверенным, что отправленные данные достигнут адресата. Очевид- 
   но, что клиенты должны продолжать давать команды получения дан- 
   ных с уже закрытых соединений, поскольку чужая программа будет 
   еще пытаться переслать оставшиеся у нее данные. Итак, команду 
   CLOSE следует интерпретировать как "у меня нет больше данных 
   для пересылки", а не как "я больше не хочу ничего получать". 
   Может случиться (если протокол на уровне клиента не продуман до 
   конца), что сторона, закрывающая соединение, не сможет изба- 
   виться от всех своих данных до истечения контрольного времени. 
   В этом случае команда CLOSE транслируется в ABORT, и программа 
   TCP отказывается от соединения.
      Клиент может дать команду CLOSE в любой момент по своему 
   собственному усмотрению, а также в ответ на различные сообщения 
   от протокола TCP (например, когда выполнено закрытие соединения 
   с чужой стороны, превышено контрольное время передачи, адресат 
   недоступен).
      Поскольку закрытие соединения требует общения с чужой про- 
   граммой TCP, то соединения могут пребывать в закрытом состоянии 
   короткое время. Попытки повторно открыть соединение до того, 
   как программа TCP отреагирует на команду CLOSE, приведет к воз- 
   врату на вызов сообщения об ошибке.
      Команда закрытия предполагает выполнение операции проталки- 
   вания данных через соединение.

Команда определения статуса соединения
   Формат
   STATUS (местное имя соединения) -> информация о статусе
     Это команда клиента, зависящая от конкретной реализации. Она 
   должна выполняться без опасных последствий для системы. Возвра- 
   щаемая клиенту информация обычно получается из блока TCB, свя- 
   занного с данным соединением, Данная команда возвращает блок 
   данных с информацией о
   - местном сокете
   - чужом сокете
   - местном имени соединения
   - окне получения
   - окне отправления
   - статусе соединения
   - количестве буферов, ждущих подтверждения
   - количестве буферов, ожидающих получения данных
   - статусе срочности
   - приоритете
   - безопасности/закрытости
   - контрольном времени пересылки
      В зависимости от состояния соединения или от особенностей 
   реализации протокола, часть указанной информации может быть не- 
   доступна или не имеет смысла. Если процесс, осуществивший вы- 
   зов, не имеет прав на использование данного соединения, то воз- 
   вращается сообщение об ошибке. Такой подход не позволяет не 
   имеющим полномочий процессам получать информацию о соединении. 

Команда ликвидации соединения
   Формат
   ABORT (местное имя соединения)
      Выполнение данной команды приводит к ликвидации всех неза- 
   конченных операций посылки и получения данных. Блок TCB ликви- 
   дируется, а также должно быть послано специальное сообщение 
   RESET программе TCP на другом конце соединения. В зависимости 
   от реализации протокола, клиенты могут получать сообщение о 
   ликвидации в ответ на каждый оставшийся невыполненным запрос о 
   посылке или получении данных. Или же клиенты вместо этого могут 
   просто получить подтверждение команды ABORT.

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

     Интерфейс программы TCP с протоколом более низкого уровня    
   Программа протокола TCP для реальной посылки информации по се- 
ти, а также для ее получения делает запросы к модулю протокола 
нижнего уровня. Одним из примеров такой реализации является систе- 
ма ARPA Internetwork, где модулем нижнего уровня является Internet 
протокол (IP) [2].
   Если протоколом более низкого уровня является IP, то он в ка- 
честве аргументов вызова запрашивает требуемый тип сервиса и время 
жизни данных в сети. Программа протокола TCP использует следующие 
значения для упомянутых параметров:
   Тип сервиса = приоритет: обычный, задержка: нормальная, 
      пропускная способность: нормальная, надежность: нормальная, 
      т.е. 00000000
   Время жизни = одна минута, или 00111100
   Заметим, что принято максимальное время жизни сегмента в две 
минуты. Здесь мы явным образом определяем, что сегмент должен быть 
ликвидирован, если он в течении одной минуты не достигает адресата 
в системе Internet.
   Если ниже расположен протокол IP (или какой-либо другой прото- 
кол с теми же функциями) и применяется процедура маршрутизации, то 
интерфейс должен допускать передачу информации о маршруте. Это 
особенно важно, поскольку адреса отправителя и получателя, учиты- 
ваемые в контрольной сумме TCP протокола, будут соответствовать 
действительному отправителю данных и самому последнему адресату. 
Важно также сохранять обратный маршрут для ответов на запросы со- 
стояния.
  Любой протокол нижнего уровня будет обязан предоставить адрес 
отправителя, адрес получателя, поля протокола, некую процедуру 
определения "длины TCP сообщения", необходимую как для сервистных 
функций протокола IP, так и для проверки контрольной суммы в самом 
протоколе TCP.
Назад       Содержание       Вперёд