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