tcp连接时，BROKENPIPE错误的原因以及解决方法
tcp连接时，BROKEN PIPE错误的原因以及解决方法
问题：
写了一个server和一个client，UNIX套接字的，server不断接收消息并打印出来，client是一个交互程序，输入一个消息回车发送，接着又可以输入消息。
出问题了：
当server监听着，client第一次发送消息成功，server接收并打印出来了。
client第二次发送消息没成功并且结束程序了，server没接收到消息，保持继续监听。
我用GDB调试时，发现client第二次发送消息时，client收到SIGPIPE(Broken Pipe)信号。server明明还监听着，而且再次启动client还是第一次成功，第二次失败退出。
同样的，当client因为断开（关闭了网络描述符sfd，或者ctrl+c/ctrl+异常断开），server端也产生SIGPIPE信号。
分析：
TCP协议是端到端的传输控制协议，之所以是“端到端”的协议，是因为”路由“是由IP协议负责的，TCP协议负责为两个通信端点提供可靠性保证，这个可靠性不是指一个端点发送的数据，另一个端点肯定能收到（这显然是不可能的），而是指，数据的可靠投递或者故障的可靠通知。
所谓的“端到端”，指的是在通信两端之间建立了一个全双工的通信管道，既然是管道，就不得不了解管道。
管道的特点：
- 管道是半双工的，数据只能向一个方向流动；需要双方通信时，需要建立起两个管道；
- 只能用于父子进程或者兄弟进程之间（具有亲缘关系的进程）；
- 单独构成一种独立的文件系统：管道对于管道两端的进程而言，就是一个文件，但它不是普通的文件，它不属于某种文件系统，而是自立门户，单独构成一种文件系统，并且只存在与内存中。
- 数据的读出和写入：一个进程向管道中写的内容被管道另一端的进程读出。写入的内容每次都添加在管道缓冲区的末尾，并且每次都是从缓冲区的头部读出数据。
管道特性的表现：
- 如果一个进程以只写打开管道，但是没有以只读或读写打开这个管道的进程，则打开操作会阻塞， 直到有进程以读或读写打开，open 才会返回。（写端打开，读端关闭）
- 如果一个进程以只读打开管道，但是没有以只写或读写打开这个管道的进程，则打开操作会阻塞， 直到有进程以写或读写打开，open 才会返回。（写端关闭，读端打开）
- 当写端没有写入数据时，读端会阻塞到 read 调用，直到写端写入数据或者写端关闭。 当管道没有空间时，再写入数据就会被阻塞。直到有进程读取数据，或者所有的读端关闭。（读写顺序）
注意：全双工，指的是每一端都可读可写。前提是对端打开。如果对端都关闭了，本端读数据为空，不会出错；但本段写数据肯定出错。
总结：
如果要进行顺利的管道通信：管道的两端必需都打开。
- 管道读端关闭，写端不能写，否则会发出SIGPIPE信号，即会生成BROKEN PIPE错误。
也就是说tcp通信时，client端通过 pipe发送信息到server端后，client端挂不必，这时server端返回信息，向pipe些内容，就会出错。
解决方法：
- 忽略SIGPIPE信号
1、signal(SIGPIPE,SIG_INT);//（全局范围内）
2、setsocketop；//（tcp特性设置）
1
2
3
/// sock 就是设置不发送 `SIGPIPE` 信号的 socket 变量
int
value = 1;
setsockopt(sock, SOL_SOCKET, SO_NOSIGPIPE, &value,
sizeof
(value));
- 合理规避读端关闭，写端打开的问题。（避免client端关闭，server端发送数据这种情况）
以上是 tcp连接时，BROKENPIPE错误的原因以及解决方法 的全部内容， 来源链接： utcz.com/z/517415.html
