В чем разница между read () и recv () и между send () и write ()?

Question

В чем разница между read () и recv () и между send () и write ()?

140

В чем разница между read() и recv(), а также между send() и write() в программировании сокетов? производительность и скорость и другое поведение.

SjB 24 нояб. 2009, в 15:08

Источник

3

#define write(...) send(##__VA_ARGS__, 0) что запись реализована следующим образом: #define write(...) send(##__VA_ARGS__, 0) .
carefulnow1 07 янв. 2017, в 09:39

Теги:

c

unix

sockets

network-programming

posix

6 ответов

68

Пер первый хит в Google

read() эквивалентно recv() с параметром flags из 0. Другие значения параметра flags изменяют поведение recv(). Аналогично, write() эквивалентен send() с флагами == 0.

Jonathan Feinberg 24 нояб. 2009, в 17:06

26

Это не вся история. recv можно использовать только в сокете, и он выдаст ошибку, если вы попытаетесь использовать его, скажем, в STDIN_FILENO .
Joey Adams 31 июль 2011, в 05:29
63

Эта тема стала первым хитом в Google, Google любит stackoverflow
Eloff 08 янв. 2013, в 21:14

7

read() и write() являются более универсальными, они работают с любым файловым дескриптором. Однако они не будут работать в Windows.

Вы можете передать дополнительные параметры send() и recv(), поэтому вам, возможно, придется использовать их в некоторых случаях.

Bastien Léonard 18 янв. 2010, в 18:30

6

Недавно я заметил, что когда я использовал write() в сокете в Windows, он почти работает (FD, переданный в write(), не совпадает с переданным в send(); я использовал _open_osfhandle() чтобы передать FD на write()). Однако это не сработало, когда я попытался отправить двоичные данные, содержащие символ 10. write() где-то вставленный символ 13 до этого. Изменив его на send() с параметром flags из 0, эта проблема была исправлена. read() может иметь обратную проблему, если 13-10 являются последовательными в двоичных данных, но я их не тестировал. Но это, по-видимому, еще одна возможная разница между send() и write().

ajb 07 июнь 2013, в 17:24

1

+1. Смотрите также winsock, не поддерживающий чтение / запись
Joseph Quinsey 19 июнь 2014, в 15:14

3

Другое дело в Linux:

send не позволяет работать с не-socket fd. Таким образом, например, для записи на порт usb требуется write.

Mert Mertce 22 сен. 2015, в 15:07

3

"Производительность и скорость"? Разве это не... синонимы здесь?

Во всяком случае, вызов recv() принимает флаги, которые read() не делает, что делает его более мощным или, по крайней мере, более удобным. Это одно отличие. Я не думаю, что существует значительная разница в производительности, но не проверена.

unwind 24 нояб. 2009, в 16:44

15

Возможно, отсутствие необходимости иметь дело с флагами может быть воспринято как более удобное.
semaj 24 нояб. 2009, в 16:16

Ещё вопросы

#define write(...) send(##__VA_ARGS__, 0) что запись реализована следующим образом: #define write(...) send(##__VA_ARGS__, 0) .
Это не вся история. recv можно использовать только в сокете, и он выдаст ошибку, если вы попытаетесь использовать его, скажем, в STDIN_FILENO .
Эта тема стала первым хитом в Google, Google любит stackoverflow
+1. Смотрите также winsock, не поддерживающий чтение / запись
Возможно, отсутствие необходимости иметь дело с флагами может быть воспринято как более удобное.

Gonzalo · Accepted Answer · 2009-11-24T16-50-00.000Z

84

Лучший ответ

Единственное различие заключается в том, что recv/send позволяет указать определенные параметры для фактической операции. чтение/запись - это универсальные функции дескриптора файла, в то время как recv/send немного более специализированы (например, вы можете установить флаг для игнорирования SIGPIPE или для отправки сообщений вне диапазона...).

Gonzalo 24 нояб. 2009, в 16:50

2

Это неверно, есть еще одно отличие в случае дейтаграмм 0 длины - если дейтаграмма нулевой длины находится в состоянии ожидания, read (2) и recv () с аргументом flags, равным нулю, обеспечивают другое поведение. В этом случае read (2) не имеет никакого эффекта (дейтаграмма остается ожидающей), тогда как recv () использует ожидающую дейтаграмму.
Abhinav Gauniyal 11 фев. 2017, в 08:44
2

@AbhinavGauniyal Как это обеспечит другое поведение ? При наличии 0-байтовой дейтаграммы и recv и read не доставят вызывающей стороне никаких данных, но также не сообщат об ошибке. Для звонящего поведение такое же. Вызывающий может даже не знать ничего о дейтаграммах (он может не знать, что это сокет, а не файл, он может не знать, что это сокет дейтаграммы, а не сокет потока). То, что датаграмма остается в ожидании, является неявным знанием того, как стеки IP работают в ядрах и невидимы для вызывающей стороны. С точки зрения вызывающих, они все равно будут обеспечивать равное поведение.
Mecki 19 июль 2017, в 16:51
2

@Mecki, это не скрытые знания для всех, возьмите меня к примеру :)
Abhinav Gauniyal 20 июль 2017, в 12:12
0

@Mecki, если дейтаграмма остается в ожидании только в сценарии read , не приведет ли это к многократному «успешному» повторному read с read нулевой длины (так, бесконечно)?
sehe 20 сен. 2018, в 11:48
0

@sehe read 0 байтов без ошибок задокументировано как «конец потока». Так что да, вы можете продолжать чтение до тех пор, пока вы этого не сделаете, но система уже сказала вам, что вы находитесь в конце, поэтому вы не можете ожидать больше данных для чтения. Для recv то же самое задокументировано для потоковых сокетов (например, TCP). Сокеты дейтаграмм (например, UDP) не имеют ни начала, ни конца, поэтому возвращение нулевых байтов не имеет для них определенного значения.
Mecki 20 сен. 2018, в 13:26
1

@Mecki, что означает неблокирующее успешное чтение 0 байтов? Датаграмма все еще остается в ожидании? Именно это и только это беспокоит меня: поведение, которое дейтаграмма может ожидать, даже если успешно прочитано. Я не уверен, что ситуация может возникнуть, поэтому я хотел бы иметь это в виду.
sehe 20 сен. 2018, в 13:28
2

@sehe Если вы беспокоитесь, почему бы вам не использовать recv ? Причиной того, что recv и send введены в первую очередь, был тот факт, что не все концепции дейтаграмм можно было сопоставить с миром потоков. read и write обрабатывают все как поток данных, будь то канал, файл, устройство (например, последовательный порт) или сокет. Тем не менее, сокет является только реальным потоком, если он использует TCP. Если он использует UDP, он больше похож на блочное устройство. Но если обе стороны используют его как поток, он будет работать как поток, и вы даже не сможете отправить пустой пакет UDP с помощью вызовов write , поэтому такой ситуации не возникнет.
Mecki 20 сен. 2018, в 15:31
1

@Mecki - это подход, к которому я стремился. Просто унаследованный код использует интерфейс стиля read и я бы предпочел быть более уверенным, что это действительно нормально (с неблокирующими чтениями). Спасибо за ваши уточняющие замечания. Это действительно полезно. Мне нравится, когда люди тратят время на то, чтобы поделиться этим с трудом заработанным опытом. Ура!
sehe 20 сен. 2018, в 15:34

Показать ещё 6 комментариев