当服务器close一个连接时,若client端接着发数据.根据TCP协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了. Linux下测试,然后用C++写了客户端用千万级别数量的短链接进行压力测试.  但是服务器总是莫名退出,没有core文件. signal(SIGPIPE, SIG_IGN); 我的程序产生这个信号的原因是:  client端通过 pipe 发送信息到server端后,就关闭cl…

当客户端close关闭连接时,若server端接着发送数据,根据TCP协议的规定,server端会收到RST响应,当server端再次往客户端发送数据时,系统会发出一个SIGPIPE信号给server进程,告诉server进程,对端连接已经关闭了,不要再写数据了.然而,根据信号的默认规则,SIGPIPE信号的默认处理动作是terminate(终止),所以server进程会结束.这样就造成了服务器因客服端的关闭而关闭. 商业开发中,这种情况是不能被允许的.避免这种情况的方法是忽略SIGPIPE信号…

转自:http://blog.csdn.net/lmh12506/article/details/8457772 前一段面试的时候被问到项目中有没有处理SIGPIPE信号,怎么处理的?当时没有答出来,今天终于找到答案了,记录一下. SIGPIPE信号详解 当服务器close一个连接时,若client端接着发数据.根据TCP协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了. 我写了一个服务器程序,…

#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <unistd.h> #include <errno.h> #include <signal.h> #include <string.h> #include <assert.h> #include…

#include <stdlib.h> #include <sys/signal.h> void SetupSignal() { struct sigaction sa; //在linux下写socket的程序的时候,如果尝试send到一个disconnected socket上,就会让底层抛出一个SIGPIPE信号. //这个信号的缺省处理方法是退出进程 //重载这个信号的处理方法,如果接收到一个SIGPIPE信号,忽略该信号 sa.sa_handler = SIG_IGN; s…

对一个对端已经关闭的socket调用两次write, 第二次将会生成SIGPIPE信号, 该信号默认结束进程.具体的分析可以结合TCP的"四次握手"关闭. TCP是全双工的信道, 可以看作两条单工信道, TCP连接两端的两个端点各负责一条. 当对端调用close时, 虽然本意是关闭整个两条信道, 但本端只是收到FIN包. 按照TCP协议的语义, 表示对端只是关闭了其所负责的那一条单工信道, 仍然可以继续接收数据. 也就是说, 因为TCP协议的限制, 一个端点无法获知对端的socket是…

我写了一个服务器程序,在Linux下测试,然后用C++写了客户端用千万级别数量的短链接进行压力测试.  但是服务器总是莫名退出,没有core文件. 最后问题确定为, 对一个对端已经关闭的socket调用两次write, 第二次将会生成SIGPIPE信号, 该信号默认结束进程. 具体的分析可以结合TCP的"四次握手"关闭. TCP是全双工的信道, 可以看作两条单工信道, TCP连接两端的两个端点各负责一条. 当对端调用close时, 虽然本意是关闭整个两条信道, 但本端只是收到FIN包.…

往一个已经接受FIN的套接中写是允许的,接受到FIN仅仅代表对方不再发送数据. 在收到RST段之后,如果在调用write就 会产生SIGPIPE信息,对于这个信号的处理我们通常 解决方法 signal(SIGPIPE,SIG_ING)…

我写socket相关的程序也不是一天两天了,在我的记忆中,只要处理好recv(或read)的返回值中<0,==0,>0三种情况,程序便不会有什么问题.但最近在看公司的源代码时,发现代码中直接将SIGPIPE设置为SIG_IGN.而且附上一段注释:往一个已经关闭的socket写入数据会触发SIGPIPE.我心中顿时一惊,我以前从来没这样做过,虽然没出问题,难道只是我运气好? 周末,决定验证一下. 首先,socket的读事件中,返回0表示socket已关闭.如果已经关闭,再往里面写东西肯定会出问题…

如果在write调用期间对方关闭连接,视时间顺序的不同有以下几种情况: 1. 刚好在write调用之前对方关闭: write返回失败,同时产生SIGPIPE. 2. write调用过程中对方关闭: 返回已写入的字节数,同时产生SIGPIPE. SIGPIPE的默认行为是终止程序,所以一般来说我们需要catch之: static void do_sig_pipe(int sig) { } your_function(...) { ... signal(SIGPIPE, do_sig_pipe);…