#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

当客户端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信号给进程,告诉进程这个连接已经断开了,不要再写了. 我写了一个服务器程序,

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

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

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

#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

GDB调试网络程序时,会遇到SIGPIPE信息,默认GDB会把程序停下来,即使程序使用signal(SIGPIPE, SIG_IGN);来忽略信号.用handle命令设置一下缺省的signal的处理行为即可:(在gdb模式下运行下面的命令)     handle SIGPIPE nostop print如果连信息提示都不想看见,可以这样设置:    handle SIGPIPE nostop noprint

往一个已经接受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);

http://blog.chinaunix.net/uid-20135786-id-3409085.html 问题描述: 我的一个服务器程序, 在Windows下运行正常. 但当在Linux(centos 6.3)下,进行对端未开启的异常测试时,出现莫名退出 . 最后跟踪到是write调用导致退出. 用gdb执行程序, 退出时提示"Broken pipe". 问题分析: 对一个对端已经关闭的socket调用两次write, 第二次将会生成SIGPIPE信号, 该信号默认结束进程. 具体

http://www.cppblog.com/elva/archive/2008/09/10/61544.html 收集一些网上的资料,以便参考: http://blog.chinaunix.net/u2/69143/showart_1087349.html 当服务器close一个连接时,若client端接着发数据.根据TCP协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了.    根据信号的默

PS: 如果服务器程序不忽略SIGPIPE,在某些时候TCP writer收到这个信号,会导致进程退出 The rule that applies is: When a process writes to a socket that has received an RST, the SIGPIPE signal is sent to the process. The default action of this signal is to terminate the process, so the

回顾一下“"开篇 -- 知其然,知其所以然"”中的两段代码,第一段虽然只使用1个线程但却也只能处理一个socket,第二段虽然能处理成百上千个socket但却需要创建同等数量的线程,分开来看都不完美,如果1个线程能够处理成百上千个socket就太好了! 问题在于,当前的实现中1个线程只能阻塞的recv等待网络数据的到来,recv在数据到来之前会挂起并让出cpu直到数据到来后才能继续执行,在此之前cpu是空闲的,并且你也无法获得cpu使用权. 如果可以趁着这个socket数据没到来之前先

最近几天用C++写了一个简单的HTTP服务器,作为学习网络编程和Linux环境编程的练手项目,这篇文章记录我在写一个HTTP服务器过程中遇到的问题和学习到的知识. 服务器的源代码放在Github. HTTP基础知识 写HTTP服务器当然要了解HTTP的基础知识.HTTP/1.1由RFC2616定义,它和TCP/IP协议族内的其他协议相同,是用于客户和服务器之 间的通信.请求访问资源的一端成为客户端,而提供资源响应的一端成为服务器端.我们要写的是服务端. HTTP请求报文 HTTP协议规定,请求从

CocoSocket分享 cocos2dx 3.1都出了,但依然没有发现与它原生的SOCKET支持,于是,这几天在家,手工撸了一个. 目前版本对IOS,ANDROID,WINDOWS支持良好.且为异步SOCKET,不需要再开任何线程. 特点1.异步SOCKET,无需任何线程2.只有一个头文件,使用方便3.支持IOS,ANDROID,WINDOWS 下载连接 v0.0.1 下载连接 v0.0.2 示例: //自定义消息处理器 class CSessionHandler :public ISocke

login_server是TeamTalk的登录服务器,负责分配一个负载较小的MsgServer给客户端使用,按照新版TeamTalk完整部署教程来配置的话,login_server的服务端口就是8080,客户端登录服务器地址配置如下(这里是win版本客户端): 1.login_server启动流程 login_server的启动是从login_server.cpp中的main函数开始的,login_server.cpp所在工程路径为server\src\login_server.下表是logi

linux网络编程之socket(十):shutdown 与 close 函数的区别  http://blog.csdn.net/yijiu0711/article/details/17349169 socket中关闭套接字的函数close和shutdown区别 #include <unistd.h> int close(int fd); close 关闭了自身数据传输的两个方向.关闭本进程的socket id,但链接还是开着的,用这个socket id的其它进程还能用这个链接,能读或写这个s

内容提要: 管道简介 使用无名管道实现一个简单的本地文件服务器 使用标准I/O函数库提供的管道实现 使用popen实现本地文件服务器 有名管道-FIFO 使用FIFO改写本地文件服务器 管道和FIFO的额外属性 使用FIFO将本地文件服务器改写成单服务器多客户端 FIFO和NFS的关系 字节流和消息 使用自定义的结构化接口改写单服务多客户端程序 管道和FIFO的限制 1.管道简介 Unix中的进程间通信方式之一是通过管道实现的,管道分为有名管道和无名管道,对于有名管道FIFO,可以实现没有亲缘关