процессы могут "владеть"портами и что процессы могут инициировать со- единения только с тех портов, которыми они владеют. (С точки зрения реализации протокола "владение" ограничивается хост-компьютером, од- нако мы можем представить себе команду пользователя по запросу порта (Request Port) или же метод выделения группы уникальных портов данно- му процессу, например посредством ассоциирования старших байтов в имени порта с данным процессом). Соединение задается командой OPEN (открыть), сделанной с локально- го порта и имеющей аргументом чужой сокет. В ответ на такой запрос программа протокола TCP предоставляет имя локального (короткого) со- единения. По этому имени пользователь адресуется к данному соединению при последующих вызовах. О соединениях следует помнить кое-какие вещи. Мы предполагаем, что имеется некая структура данных, называемая бло- ком управления передачей (Transmission Control Block -TCB), предназ- наченная для сохранения описанной выше информации. Можно было бы ре- ализовать протокол таким образом, чтобы локальное имя для соединения было бы указателем на структуру TCB последнего. Запрос OPEN указывает также, осуществляется ли соединение активным образом, или же происхо- дит пассивное ожидание соединения извне. Запрос на пассивное открытие соединения означает, что процесс ждет получения извне запросов на соединение, вместо того, чтобы пытаться самому установить его. Часто процесс, сделавший запрос на пассивное открытие, будет принимать запросы на соединение от любого другого процесса. В этом случае чужой сокет указывается как состоящий целиком из нулей, что означает неопределенность. Неопределенные чужие сокеты могут присутствовать лишь в командах пассивного открытия. Сервисный процесс, желающий обслужить другие, неизвестные ему про- цессы, мог бы осуществить запрос на пассивное открытие с указанием неопределенного сокета. В этом случае соединение может быть установ- лено с любым процессом, запросившим соединения с этим локальным соке- том. Такая процедура будет полезна, если известно, что выбранный ло- кальный сокет ассоциирован с определенным сервисом. Общеизвестные сокеты представляют собой удобный механизм априорно- го привязывания адреса сокета с каким-либо стандартным сервисом. На- пример, процесс "сервер для программы Telnet" жестко связан с кон- кретным сокетом. Другие сокеты могут быть зарезервированы за передат- чиком файлов, Remote Job Entry, текстовым генератором, эхо-сервером, а также Sink-процессами (последние три пункта связаны с обработкой текстов). Адрес сокета может быть зарезервирован для доступа к проце- дуре "просмотра", которая могла бы указывать сокет, через который можно было бы получить новообразованные услуги. Концепция общеизвест- ного сокета является частью TCP спецификации, однако собственно асо- циирование сокетов с услугами выходит за рамки данного описания про- токола (см. документ [4]). Процессы могут осуществлять пассивные открытия соединений и ждать, пока от других процессов придут соответсвующие завпросы на активное открытие, а протокол TCP проинформирует их об установлении соедине- ния. Два процесса, сделавшие друг другу одновременно запросы на ак- тивное открытие, получат корректное соединение. Гибкость такого под- хода становится критичной при поддержке распределенных вычислений, когда компоненты системы взаимодействуют друг с другом асинхронным образом. Когда осуществляется подбор сокетов для локального запроса пассив- ного открытия и чужого запроса на активное открытие, то принципиаль- ное значение имеют два случая. В первом сслучае местное пассивное от- крытие полностью определяет чужой сокет. При этом подбор должен осу- ществляться очень аккуратно. Во втором случае во время местного пас- сивного открытия чужой сокет не указывается. Тогда в принципе может быть установлено соединение с любых чужих сокетов. Во всех остальных случаях подбор сокетов имеет частичные ограничения. Если на один и тот же местный сокет осуществлено несколько ждущих пассивных запросов на открытие (записанных в блоки TCB), и осущест- вляется извне активный запрос на открытие, то чужой активный сокет будет связываться с тем блоком TCB, где было указание именно на этот запросивший соединения сокет. И только если такого блока TCB не су- ществует, выбор партнера осуществляется среди блоков TCB с неопреде- ленным чужим сокетом. Процедура установки соединения использует флаг управления синхро- низацией (SYN) и трижды обменивается сообщениями. Такой обмен называ- ется трехвариантным подтверждением [3]. Соединение инициируется при встрече пришедшего сегмента, несущего флаг синхронизации (SYN), и ждущей его записи в блоке TCB. И сегмент и запись создаются пришедшими от пользователей запросами на открытие. Соответствие местного и чужого сокетов устанавливается при инициали- зации соединения. Соединение признается установленным, когда номера очередей синхронизированы в обоих направлениях между сокетами. Отмена соединения также включает обмен сегментами, несущими на этот раз управляющий флаг FIN. 2.8 Коммуникация данных Набор данных, передаваемых по соединению, можно рассматривать как поток октетов. Пользователь, отправляющий данные, указывает при за- просе по посылку, следует ли данные, отправляемые при этом запросе, немедленно проталкивать через сеть к получателю. Указание осуществля- ется установкой флага PUSH (проталкивание). Программа протокола TCP может собирать данные, принимаемые от пользователя, а затем передавать их в сеть по своему усмотрению в ви- де сегментов. Если же выставлен запрос на проталкивание, то протокол должен передать все неотправленные ранее данные. Когда программа про- токола TCP, принимающая данные, сталкивается с флагом проталкивания, ей не следует ожидать получения новых данных по сети до тех пор, пока уже имеющиеся данные не будут переданы ждущему их местному процессу. Нет нужды привязывать функции проталкивания к границам сегмента. Данные, содержащиеся в каком-либо сегменте, могут быть результатом одного или нескольких запросов на посылку. Или же один запрос может породить несколько сегментов. Целью функции проталкивания и флага PUSH является проталкивание данных через сеть от отправителя к получателю. Функция не осуществляет обработки самих данных. Существует связь между функцией