linux手册翻译——recv(2)

recv, recvfrom, recvmsg - receive a message from a socket

recv()、recvfrom() 和 recvmsg() 调用用于从套接字接收消息。 它们可用于在UDP和TCP的套接字上接收数据。 本页首先介绍了所有三个系统调用的共同特点，然后介绍了调用之间的区别。

recv() 和 read(2) 之间的唯一区别是 flags 的存在。 使用零标志参数，recv() 通常等效于 read(2) (但请参阅 NOTES)，且

recv(sockfd, buf, len, flags)

等价于

recvfrom(sockfd, buf, len, flags, NULL, NULL)

所有三个调用都在成功完成时返回消息的长度。 如果消息太长而无法放入提供的缓冲区，则 可能 会丢弃多余的字节，具体 取决于接收消息的套接字类型 ，显然TCP是不可能丢弃的。

如果套接字上没有可用消息，则接收调用将等待消息到达，除非套接字是非阻塞的（请参阅 fcntl(2)），在这种情况下，将返回值 -1 并将 errno 设置为 EAGAIN 或 EWOULDBLOCK。 recv_()调用通常会返回任何可用的数据，只要拿到数据就会立马返回，最多返回指定缓冲区大小的数据，但是并不会等待到让缓冲区满 ，除非设置了 MSG_WAITALL 标志，见下。

应用程序可以使用 select(2)、poll(2) 或 epoll(7) 来确定更多数据何时到达。

The flags argument is formed by ORing one or more of the following values:

ee_errno contains the errno number of the queued error. ee_origin is the origin code of where the error originated. The other fields are protocol-specific. The macro SOCK_EE_OFFENDER returns a pointer to the address of the network object where the error originated from given a pointer to the ancillary message. If this address is not known, the sa_family member of the sockaddr contains AF_UNSPEC and the other fields of the sockaddr are undefined. The payload of the packet that caused the error is passed as normal data.

For local errors, no address is passed (this can be checked with the cmsg_len member of the cmsghdr ). For error receives, the MSG_ERRQUEUE flag is set in the msghdr . After an error has been passed, the pending socket error is regenerated based on the next queued error and will be passed on the next socket operation.

recvfrom() 将接收到的消息放入缓冲区 buf 。 调用者必须在 len 中指定缓冲区的大小。

如果调用者希望拿到消息的原地址， 并且底层协议可以提供消息的源地址时，应将 src_addr 设置为指向用于接收消息原地址的缓冲区。 在这种情况下， addrlen 是一个 value-result 参数。 在调用之前，它应该被初始化为与 src_addr 关联的缓冲区的大小。 返回时，addrlen 被更新以包含源地址的实际大小。 如果提供的缓冲区太小，则截断返回的地址； 在这种情况下， addrlen 将返回一个大于提供给调用的值。

如果调用者对源地址不感兴趣，则应将 src_addr 和 addrlen 指定为 NULL。

ssize_t recv(int sockfd, void* buf, size_t len, int flags)

recv() 调用通常仅用于已连接的套接字（请参阅 connect(2)）。 相当于调用：

recvfrom(fd, buf, len, flags, NULL, 0)

ssize_t recvmsg(int sockfd, struct msghdr* msg, int flags)

recvmsg() 调用使用 msghdr 结构来 最小化直接提供的参数数量 。 这个结构在 <sys/socket.h>中定义如下：

msg_name 字段指向调用者分配的缓冲区，如果套接字未连接（ 特指UDP的服务端 ），则该缓冲区用于返回源地址。 调用者应在此调用之前将 msg_namelen 设置为此缓冲区的大小； 从成功调用返回后，msg_namelen 将包含返回地址的长度。 如果应用程序不需要知道源地址，可以将 msg_name 指定为 NULL。

The fields msg_iov and msg_iovlen describe scatter-gather locations, as discussed in readv(2).

需要注意的是 msg_iov 和 msg_iovlen 描述了一个 struct iovec 类型的数组， msg_iovlen 表示数组的元素个数，而struct iovec则是描述了一个缓冲区

字段 msg_control 指向用于其他协议控制相关消息或杂项辅助数据的缓冲区。 当recvmsg()被调用时， msg_controllen 为 msg_contro l中可用缓冲区的长度； 从成功调用返回时，它将被设置为控制消息序列的长度。

控制消息的格式为：

只能通过 cmsg(3) 中定义的宏访问辅助数据。

例如，Linux 使用这种辅助数据机制通过 UNIX 域套接字传递扩展错误、IP 选项或文件描述符。 有关在各种套接字域中使用辅助数据的更多信息，请参阅 unix(7) 和 ip(7)。

msghdr 中的 msg_flags 字段在 recvmsg() 返回时设置 。 它可以包含几个标志：

这些调用返回接收到的字节数，如果发生错误，则返回 -1。 如果发生错误，则设置 errno 以指示错误。

当流套接字对等端执行有序关闭(orderly shutdown)时，返回值将为 0（传统的“文件结束”返回）。

各种域（例如 UNIX 和 Internet 域）中的数据报套接字允许零长度数据报。 当收到这样的数据报时，返回值为 0。

如果从流套接字接收的请求字节数为 0，则也可能返回值 0。

这些是套接字层生成的一些标准错误。 底层协议模块可能会产生和返回额外的错误； 查看他们的手册页。

POSIX.1-2001, POSIX.1-2008, 4.4BSD (these interfaces first appeared in 4.2BSD).

POSIX.1 describes only the MSG_OOB, MSG_PEEK, and MSG_WAITALL flags.

如果零长度数据报未决，则带有零标志参数的 read(2) 和 recv() 提供不同的行为。 在这种情况下， read(2) 不起作用（数据报保持挂起），而 recv() 消耗挂起的数据报。

socklen_t 类型是由 POSIX 发明的。 另见 accept(2) 。

根据 POSIX.1，msghdr 结构的 msg_controllen 字段类型为 socklen_t，而 msg_iovlen 字段类型为 int，但 glibc 目前将两者设置为 size_t。

有关可用于在单个调用中接收多个数据报的 Linux 特定系统调用的信息，请参阅 recvmmsg(2)。

getaddrinfo(3) 中显示了使用 recv() 的示例。

Linux 实现 IPC 其中的一种方式——管道

管道又分：

1、无名管道：无名管道只能用于有亲缘关系的进程。

2、有名管道：有名管道用于任意两进程间通信。

你就可以把管道理解成位于进程内核空间的“文件”。

给文件加引号，是因为它和文件确实很像，因为它也有描述符。但是它确实又不是普通的本地文件，而是一种抽象的存在。

当进程使用 pipe 函数，就可以打开位于内核中的这个特殊“文件”。同时 pipe 函数会返回两个描述符，一个用于读，一个用于写。如果你使用 fstat函数来测试该描述符，可以发现此文件类型为 FIFO。

而无名管道的无名，指的就是这个虚幻的“文件”，它没有名字。本质上，pipe 函数会在进程内核空间申请一块内存（比如一个内存页，一般是 4KB），然后把这块内存当成一个先进先出（FIFO）的循环队列来存取数据，这一切都由 *** 作系统帮助我们实现了。

pipe 函数打开的文件描述符是通过参数（数组）传递出来的，而返回值表示打开成功（0）或失败（-1）。

它的参数是一个大小为 2 的数组。此数组的第 0 个元素用来接收以读的方式打开的描述符，而第 1 个元素用来接收以写的方式打开的描述符。也就是说，pipefd[0] 是用于读的，而 pipefd[1] 是用于写的。

打开了文件描述符后，就可以使用 read(pipefd[0]) 和 write(pipefd[1]) 来读写数据了。

注意事项

1、这两个分别用于读写的描述符必须同时打开才行，否则会出问题。

2、如果关闭读 (close(pipefd[0])) 端保留写端，继续向写端 (pipefd[1]) 端写数据(write 函数)的进程会收到 SIGPIPE 信号。

3、如果关闭写 (close(pipefd[1])) 端保留读端，继续向读端 (pipefd[0]) 端读数据(read 函数)，read 函数会返回 0。

当在进程用 pipe 函数打开两个描述符后，我们可以 fork 出一个子进程。这样，子进程也会继承这两个描述符，而且这两个文件描述符的引用计数会变成 2。

如果你需要父进程向子进程发送数据，那么得把父进程的 pipefd[0] （读端）关闭，而在子进程中把 pipefd[1] 写端关闭，反之亦然。为什么要这样做？实际上是避免出错。传统上 pipe 管道只能用于半双工通信（即一端只能发，不能收；而另一端只能收不能发），为了安全起见，各个进程需要把不用的那一端关闭（本质上是引用计数减 1）。

步骤一：fork 子进程

步骤二：关闭父进程读端，关闭子进程写端

父进程 fork 出一个子进程，通过无名管道向子进程发送字符，子进程收到数据后将字符串中的小写字符转换成大写并输出。

有名管道打破了无名管道的限制，进化出了一个实实在在的 FIFO 类型的文件。这意味着即使没有亲缘关系的进程也可以互相通信了。所以，只要不同的进程打开 FIFO 文件，往此文件读写数据，就可以达到通信的目的。

1、文件属性前面标注的文件类型是 p

2、代表管道文件大小是 0

3、fifo 文件需要有读写两端，否则在打开 fifo 文件时会阻塞

通过命令 mkfifo 创建

通过函数 mkfifo创建

函数返回 0 表示成功，-1 失败。

例如:

cat 命令打印 test文件内容

接下来你的 cat 命令被阻塞住。

开启另一个终端，执行：

然后你会看到被阻塞的 cat 又继续执行完毕，在屏幕打印 “hello world”。如果你反过来执行上面两个命令，会发现先执行的那个总是被阻塞。

有两个程序，分别是发送端 send 和接收端面 recv。程序 send 从标准输入接收字符，并发送到程序 recv，同时 recv 将接收到的字符打印到屏幕。

发送端

接收端

编译

运行

因为 recv 端还没打开test文件，这时候 send 是阻塞状态的。

再开启另一个终端：

这时候 send 端和 recv 端都在终端显示has opend fifo

此时在 send 端输入数据，recv 打印。

---