RFC 793 — Протокол управления передачей (TCP)

• Send
• Формат: SEND (локальное имя соединения, адрес буфера, счетчик байтов, флаг PUSH, флаг URGENT [, тайм-аут])

• Этот вызов заставляет передать в заданное соединение данные из указанного пользовательского буфера. Если соединение еще не организовано, вызов SEND трактуется как ошибка. Некоторые реализации могут позволять вызовы SEND до организации соединения; в таких случаях автоматически вызывается функция OPEN. Если вызывающий процесс не имеет полномочий на использование указанного соединения, возвращается сообщение об ошибке.

  Если установлен флаг PUSH, данные должны быть быстро переданы получателю и флаг PUSH устанавливается для последнего сегмента TCP, созданного из буфера. При отсутствии флага PUSH данные могут объединяться с данными от последующих вызовов SEND для повышения эффективности передачи.

  При установке флага URGENT сегмент передается получателю с указателем срочности. Принимающая сторона TCP будет сообщать о наличии срочных данных принимающему процессу, если указатель срочности еще не попадает в число обработанных этим процессом данных. Использование флага и указателя срочности позволяет стимулировать обработку срочных данных и информировать принимающий процесс о завершении приема срочной информации. Число флагов срочности на передающей стороне TCP не обязано совпадать с числом фактов информирования принимающего процесса о присутствии срочных данных.

  Если при вызове OPEN внешний сокет не был указан, но соединение организовано (например, в состоянии LISTEN принят вызов для данного локального сокета), указанный буфер передается косвенно заданному (подразумеваемому) внешнему сокету. Пользователи, вызывающие OPEN с незаданным сокетом, могут вызывать SEND, даже не зная адрес внешнего сокета.

  Однако, вызов SEND до того, как внешний сокет определится, будет приводить к возврату сообщения об ошибке. Пользователь может вызвать функцию STATUS для проверки состояния соединения. В некоторых реализациях TCP может уведомлять пользователя при отсутствии указаний на внешний сокет.

  Если задан тайм-аут, текущее время ожидания для данного соединения будет заменено новым значением.

  В простейших реализациях SEND может не возвращать управления вызвавшему процессу, пока не будет завершена передача или не истечет заданное время ожидания. Однако, такой подход может приводить к простоям (например, обе стороны соединения могут попытаться вызвать SEND до получения каких-либо данных с помощью RECEIVE) и не обеспечивает достаточной производительности, поэтому не рекомендуется к использованию. Более сложные реализации будут незамедлительно возвращать управление, позволяя процессу работать одновременно с сетевыми операциями ввода-вывода. В таких случаях может одновременно использоваться множество экземпляров SEND, обслуживание выполняется в порядке вызовов и TCP будет выстраивать данные в очередь.

  Предполагается, что взаимодействие с пользовательским уровнем происходит асинхронно и вызов SEND сопровождается генерацией некого сигнала (или псевдопрерывания) со стороны обслуживающего вызов TCP. Другим вариантом является незамедлительный отклик. Например, SEND может незамедлительно возвращать локальное подтверждение даже при отсутствии подтверждения доставки от удаленного TCP. Будем оптимистически предполагать успешную передачу. Если это не так, соединение будет разрываться по тайм-ауту. Реализации такого типа (синхронные) продолжают использовать асинхронные сигналы, но эти сигналы относятся к соединениям, а не сегментам или буферам.

  Для того, чтобы процесс мог различать сообщения (код результата) от множества SEND вместе с результатом может возвращаться адрес использованного при вызове SEND буфера. Сигналы от TCP к пользователю, обсуждаемые ниже, содержат информацию, которая должна быть возвращена вызвавшему функцию процессу.