Главная > Технологии > Протокол 3.8 ИнтерфейсыКонечно, здесь затрагиваются два интерфейса. Интерфейс клиент/ протокол TCP и интерфейс протокол TCP/протокол нижнего уровня. Мы имеем более тщательно разработанную модель для первого из них. Но здесь не рассматривается интерфейс с модулем протокола нижнего уровня, поскольку это сделано в спецификации последнего. Для случая, когда в интерфейсе нижний уровень - это протокол IP, мы лишь отметим некоторые из допустимых параметров, используемых протоколом TCP. Интерфейс клиент/TCPНижеприведенное функциональное описание команд клиента, посылаемых программе протокола TCP, является, в лучшем случае, умозрительным, поскольку каждая операционная система будет иметь свои характеристики. Следовательно, мы должны предупредить читателей о том, что различные реализации протокола TCP могут иметь различный интерфейс с клиентом. Однако, все реализации протокола TCP должны обеспечивать некий минимальный набор услуг с тем, чтобы гарантировать, что все они придерживаются единой иерархии протокола. Данная глава описывает функциональный интерфейс, обязательный для всех реализаций протокола TCP. TCP команды клиентаВ следующих параграфах функционально характеризуется интерфейс клиент/протокол TCP. Нотация вызова подобна нотации большинства процедур или нотации вызова функции в языках высокого уровня, однако это не означает неправомерность вызовов на обслуживание в виде ловушек (trap) (например SVC, UUO, EMT). Описанные ниже команды клиента определяют основные операции, которые должна выполнять программа протокола TCP для поддержки коммуникаций между процессами. Отдельные реализации протокола должны определять свой собственный конкретный формат и могут обеспечить комбинации или наборы базовых функций для одиночных вызовов. В частности, некоторые реализации могут автоматически открывать соединение (OPEN), как только по нему клиент дает первую команду посылки (SEND) или получения (RECEIVE). Для того, чтобы поддерживать интерфейс между процессами, про грамма TCP должна не только принимать команды, но и возвращать некую информацию обслуживаемым процессам. Эта информация состоит из:
Команда открытияФормат Мы полагаем, что местная программа TCP несет ответственность за идентификацию обслуживаемых процессов и будет проверять принадлежность процессов, желающих обратиться к данному соединению. В зависимости от реализации протокола TCP, либо программа TCP, либо протокол более нижнего уровня (например, IP) будут создавать адрес отправителя, а точнее, идентификаторы для локальной сети и интерфейса TCP. Такая предусмотрительность является результатом учета безопасности, а именно того, чтобы ни одна из программ TCP не смогла замаскироваться под какую-либо другую, и т.д. Аналогичным образом ни один процесс не должен замаскироваться под другой без того, чтобы не иметь конфликт с протоколом TCP. Если флаг активный/пассивный установлен в состояние "пассивный", то это означает, что дан запрос на "прослушивание" (LISTEN) сигнала установления соединения извне. Пассивное открытие может дать либо полное описание чужого сокета, с которым должно быть установлено данное соединение, либо не давать никаких указаний по поводу чужого сокета, который должен дать сигнал. Пассивное открытие соединения с четко определенным чужим сокетом может стать в любой момент активным открытым соединением, если будет дана команда на посылку данных (SEND). Создается блок управления передачей (TCB) и частично заполняется информацией, полученной от параметров команды OPEN. В случае команды на активное открытие (OPEN) протокол TCP немедленно запустит процедуру синхронизации (точнее, установления) соединения. Контрольное время, если оно присутствует среди параметров функции, позволяет клиенту установить контрольное время ликвидации для всех данных, посылаемых от имени протокола TCP. Если в течение этого контрольного времени какие-либо данные не достигли своего адресата, программа TCP ликвидирует соединение. В настоящее время общепринятым контрольным временем являются пять минут. Программа протокола TCP или какая-либо компонента операционной системы будет проверять права клиента на открытие соединения, имеющего заказанные клиентом приоритет и безопасность. Если приоритет или безопасность/закрытость не указаны, должен использоваться вызов CALL, использующий значения этих параметров, принятые по умолчанию. Программа протокола TCP будет воспринимать приходящие запросы только если они имеют тот же самый уровень безопасности/закрытости. Приоритет запросов должен быть равен или превышать приоритет, указанный в команда открытия (OPEN). Если приоритет для соединения оказывается больше, чем значение, указанное в запросе CALL, то берется приоритет из пришедшего запроса и становится постоянной характеристикой соединения. Разработчики могут перепоручить клиентам ведение переговоров по поводу установления приоритета соединения. Например, клиент может указывать приоритет, который должен быть присвоен соединению. В другом примере, любая попытка повысить приоритет соединения должна получить санкцию клиента. По завершении операции протокол TCP возвращает клиенту местное название для открытого соединения. Впоследствии имя соединения может использоваться в качестве короткого обозначения для соединения, идентифицируемого парой <местный сокет, чужой сокет >. Команда на посылку данных Формат Данная команда приводит к тому, что данные, содержащиеся в указанном клиентом буфере, передаются на указанное соединение. Если соединение не было к этому времени открытым, команда SEND является ошибочной. Некоторые реализации протокола TCP могут позволить клиентам начинать общение сразу с команды SEND. При этом команда OPEN должна осуществляться автоматически. Если процесс, давший команду на посылку, не уполномочен использовать данное соединение, команда возвращает клиенту ошибку. Если установлен флаг проталкивания (PUSH), то данные должны быть переданы по назначению с соответствующим сообщением, а бит PUSH должен быть установлен на последний из созданных в буфере TCP сегментов. Если флаг PUSH не выставлен, то имеющиеся данные могут быть объединены с данными из посылаемых следом датаграмм. Кроме того, хост-компьютер, посылающий данные, может получить сообщение от шлюза об истечении контрольного времени. Если хост-компьютер, осуществляющий сборку фрагментов дата граммы, не может в отведенное для этого время завершить свою работу из-за получения ошибочного фрагмента, то он выкидывает датаграмму и может послать сообщение об превышении контрольного времени. Этого сообщения не следует посылать вовсе, если не был получен нулевой фрагмент датаграммы. От шлюза приходит сообщение с кодом 0 ,а от хост-компьютера - сообщение с кодом 1.
Поля IP протокола: Адрес получателя Если было указано контрольное время, то в этом соединении его текущее значение, заданное клиентом, будет изменено. В простейших реализациях команда SEND не предает управление обратно вызвавшей ее программе, пока не будет завершена передача или пока не будет превышено контрольное время. Однако, такой простой метод может приводить к блокировке (на пример, когда обе стороны на концах соединения пытаются сперва выполнить команду SEND, а лишь потом - RECEIVE) и плохим эксплуатационным характеристикам. Поэтому такой подход не рекомендуется использовать. В более сложной реализации возврат из функции SEND осуществляется незамедлительно, что позволяет процессу выполняться параллельно с вводом/выводом в компьютерную сеть. И даже более того - позволяет выполнять одновременно несколько команд SEND. Множественные команды SEND обрабатываются по принципу "первый пришел первый обслужен", поэтому протокол TCP будет иметь очередь, которая не может быть обслужена мгновенно. Косвенным образом мы предположили асинхронность интерфейса с клиентом, при которой команда SEND вызывает появление особого рода сигнала или псевдо-прерывания из обслуживающей программы TCP. Альтернатива состоит в немедленном возврате из команды. Например, команды SEND могут возвращать немедленно подтверждение от местной системы, даже если посланный сегмент не получил подтверждения от чужой программы TCP. Мы оптимистически относимся к возможному успеху этой операции. Если мы ошибаемся, то соединение в любом случае будет разорвано по истечении контрольного времени. В реализациях протокола TCP такого типа (синхронных) будет все равно оставаться некоторые асинхронные сигналы, однако они будут относиться к самому соединению, а не к конкретным сегментам или буферам. Чтобы процесс мог различать сообщения об ошибках и успешное рапорты от различных команд SEND, может оказаться удобным возвращать в ответ на запрос SEND адрес буфера наряду с кодированным ответом. Сигналы между клиентом и протоколом TCP обсуждаются ниже и определяют ту информацию, которую следует возвращать отправившему команду процессу. Команда получения Формат Данная команда размещает получаемую информацию в буфере, связанном с конкретным соединением. Если команде не предшествует команда OPEN или если процесс, осуществляющий вызов, не уполномочен на использование данного соединения, то возвращается ошибка. В простейшей реализации протокола управление не должно передаваться осуществившей вызов программе до тех пор, пока либо не будет заполнен буфер, либо не произойдет какая-либо ошибка. Однако данная схема в значительной мере подвержена блокировкам. Более сложная реализация могла бы позволить за раз выдвигать несколько команд RECEIVE. Эти запросы будут выполняться по мере поступления сегментов с данными. Такая стратегия позволяет увеличить пропускную способность за счет применения более развитой схемы (возможно, асинхронной), а также оповещения программы о том, что получен сигнал проталкивания PUSH или заполнен буфер. Если получено достаточное количество данных, чтобы заполнить буфер до того, как получен сигнал проталкивания PUSH, то в ответ на RECEIVE не будет установлен флаг PUSH. Буфер будет со держать столько данных, насколько позволяет его емкость. Если сигнал PUSH обнаружен до того, как буфер заполнился, то буфер будет возвращен заполненным частично и с сигналом PUSH. Если обнаружены срочные данные, то сразу же по их прибытии клиент будет оповещен сигналом от программы протокола TCP. Клиент, получающий данные, должен по этому сигналу перейти в "срочный режим". Если флаг срочности URGENT установлен, то дополнительные срочные данные останутся неполученными. Если флаг URGENT сброшен, то данный запрос на получение RECEIVE возвратит все срочные данные и клиент может освободиться от "срочного режима". Заметим, что данные, следующие за указателем срочности (несрочные данные) не могут быть доставлены к клиенту в одном и том же буфере с предыдущими срочными данными, если сам клиент не определил четко границу. Чтобы проводить различие между несколькими сделанными командами на получение RECEIVED и следить за заполнением буферов, код, возвращаемый клиенту сопровождается как указателем на буфер, так и количеством действительно полученных данных. Другие реализации команды RECEIVE могут сами выделять буфер для размещения получаемых данных или же программа протокола TCP может одновременно с клиентом пользоваться циклическим буфером. Команда закрытия соединения Формат Данная команда приводит к закрытию указанного соединения. Если соединение не открыто или отдавший команду процесс не уполномочен использовать данное соединение, то возвращается со общение об ошибке. Предполагается, что закрытие соединения будет медлительной операцией в том смысле, что оставшиеся команды посылки SEND будут еще некоторое время передавать данные (и даже, в случае необходимости, делать это повторно), насколько это позволит управление потоком, и не будет выполнена заказанная работа. Таким образом, можно будет сделать несколько команд посылки SEND, а затем закрыть соединение командой CLOSE, будучи уверенным, что отправленные данные достигнут адресата. Очевидно, что клиенты должны продолжать давать команды получения данных с уже закрытых соединений, поскольку чужая программа будет еще пытаться переслать оставшиеся у нее данные. Итак, команду CLOSE следует интерпретировать как "у меня нет больше данных для пересылки", а не как "я больше не хочу ничего получать". Может случиться (если протокол на уровне клиента не продуман до конца), что сторона, закрывающая соединение, не сможет избавиться от всех своих данных до истечения контрольного времени. В этом случае команда CLOSE транслируется в ABORT, и программа TCP отказывается от соединения. Клиент может дать команду CLOSE в любой момент по своему собственному усмотрению, а также в ответ на различные сообщения от протокола TCP (например, когда выполнено закрытие соединения с чужой стороны, превышено контрольное время передачи, адресат недоступен). Поскольку закрытие соединения требует общения с чужой программой TCP, то соединения могут пребывать в закрытом состоянии короткое время. Попытки повторно открыть соединение до того, как программа TCP отреагирует на команду CLOSE, приведет к возврату на вызов сообщения об ошибке. Команда закрытия предполагает выполнение операции проталкивания данных через соединение. Команда определения статуса соединения Формат
В зависимости от состояния соединения или от особенностей реализации протокола, часть указанной информации может быть недоступна или не имеет смысла. Если процесс, осуществивший вы зов, не имеет прав на использование данного соединения, то воз вращается сообщение об ошибке. Такой подход не позволяет не имеющим полномочий процессам получать информацию о соединении. Команда ликвидации соединения Формат Выполнение данной команды приводит к ликвидации всех незаконченных операций посылки и получения данных. Блок TCB ликвидируется, а также должно быть послано специальное сообщение RESET программе TCP на другом конце соединения. В зависимости от реализации протокола, клиенты могут получать сообщение о ликвидации в ответ на каждый оставшийся невыполненным запрос о посылке или получении данных. Или же клиенты вместо этого могут просто получить подтверждение команды ABORT. Сообщения клиенту от программы TCPПредполагается, что сервисные функции операционной системы предоставляют программе TCP средства для асинхронной посылки сигнала. Когда программа TCP посылает сигнал программе клиента, то определенная часть информации передается также самому клиенту. Часто это осуществляется в виде сообщений об ошибках. В других случаях наряду с этим будет предоставляться информация, связанная с завершением посылки и получения данных, а также выполнением других команд клиента. Предоставляется следующая информация:
Интерфейс программы TCP с протоколом более низкого уровняПрограмма протокола TCP для реальной посылки информации по сети, а также для ее получения делает запросы к модулю протокола нижнего уровня. Одним из примеров такой реализации является система ARPA Internetwork, где модулем нижнего уровня является Internet протокол (IP) [2]. Если протоколом более низкого уровня является IP, то он в качестве аргументов вызова запрашивает требуемый тип сервиса и время жизни данных в сети. Программа протокола TCP использует следующие значения для упомянутых параметров: Тип сервиса = приоритет: обычный, задержка: нормальная, Время жизни = одна минута, или 00111100 Заметим, что принято максимальное время жизни сегмента в две минуты. Здесь мы явным образом определяем, что сегмент должен быть ликвидирован, если он в течении одной минуты не достигает адресата в системе Internet. Если ниже расположен протокол IP (или какой-либо другой протокол с теми же функциями) и применяется процедура маршрутизации, то интерфейс должен допускать передачу информации о маршруте. Это особенно важно, поскольку адреса отправителя и получателя, учитываемые в контрольной сумме TCP протокола, будут соответствовать действительному отправителю данных и самому последнему адресату. Важно также сохранять обратный маршрут для ответов на запросы состояния. Любой протокол нижнего уровня будет обязан предоставить адрес отправителя, адрес получателя, поля протокола, некую процедуру определения "длины TCP сообщения", необходимую как для сервисных функций протокола IP, так и для проверки контрольной суммы в самом протоколе TCP. Главная > Технологии > Протокол | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
