网上看到的关于SOKET SIGPIPE的两篇文章

socket关闭的close和shutdown区别[转]

转自：http://hi.baidu.com/yoshubom/blog/item/caa3b2de5d210559cdbf1a2b.html

socket关闭close和shutdown

socket关闭有2个close，shutdown

他们之间的区别:

close-----关闭本进程的socket id，但链接还是开着的，用这个socket id的其它进程还能用这个链接，能读或写这个socket id

shutdown--则破坏了socket 链接，读的时候可能侦探到EOF结束符，写的时候可能会收到一个SIGPIPE信号，这个信号可能直到

socket buffer被填充了才收到，shutdown还有一个关闭方式的参数，0 不能再读，1不能再写，2 读写都不能。

===============================================================================================================

socket 多进程中的shutdown, close使用
当所有的数据操作结束以后，你可以调用close()函数来释放该socket，从而停止在该socket上的任何数据操作：
close(sockfd);


你也可以调用shutdown()函数来关闭该socket。该函数允许你只停止在某个方向上的数据传输，而一个方向上的数据传输继

续进行。如你可以关闭某socket的写操作而允许继续在该socket上接受数据，直至读入所有数据。
int shutdown(int sockfd,int how);
Sockfd是需要关闭的socket的描述符。参数 how允许为shutdown操作选择以下几种方式：
    SHUT_RD：关闭连接的读端。也就是该套接字不再接受数据，任何当前在套接字接受缓冲区的数据将被丢弃。进程将不能对该

套接字发出任何读操作。对TCP套接字该调用之后接受到的任何数据将被确认然后无声的丢弃掉。
    SHUT_WR:关闭连接的写端，进程不能在对此套接字发出写操作
    SHUT_RDWR:相当于调用shutdown两次：首先是以SHUT_RD,然后以SHUT_WR


使用close中止一个连接，但它只是减少描述符的参考数，并不直接关闭连接，只有当描述符的参考数为0时才关闭连接。
shutdown可直接关闭描述符，不考虑描述符的参考数，可选择中止一个方向的连接。

注意:
    1>. 如果有多个进程共享一个套接字，close每被调用一次，计数减1，直到计数为0时，也就是所用进程都调用了close，套

接字将被释放。
    2>. 在多进程中如果一个进程中shutdown(sfd, SHUT_RDWR)后其它的进程将无法进行通信. 如果一个进程close(sfd)将不会

影响到其它进程. 得自己理解引用计数的用法了. 有Kernel编程知识的更好理解了.

遭遇SIGPIPE[转]

转自：

我写了一个服务器程序, 在Windows下在cygwin环境编译后执行, 然后用C#写了多线程客户端进行压力测试. 程序一直运行正常. 但当在Linux下测试时, 总是莫名退出. 最后跟踪到是write调用导致退出. 用gdb执行程序, 退出时提示"Broken pipe".

最后问题确定为, 对一个对端已经关闭的socket调用两次write, 第二次将会生成SIGPIPE信号, 该信号默认结束进程.

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

 
截图来自: UNPv1

对一个已经收到FIN包的socket调用read方法, 如果接收缓冲已空, 则返回0, 这就是常说的表示连接关闭. 但第一次对其调用write方法时, 如果发送缓冲没问题, 会返回正确写入(发送). 但发送的报文会导致对端发送RST报文, 因为对端的socket已经调用了close, 完全关闭, 既不发送, 也不接收数据. 所以, 第二次调用write方法(假设在收到RST之后), 会生成SIGPIPE信号, 导致进程退出.

为了避免进程退出, 可以捕获SIGPIPE信号, 或者忽略它, 给它设置SIG_IGN信号处理函数:

signal(SIGPIPE, SIG_IGN);

这样, 第二次调用write方法时, 会返回-1, 同时errno置为SIGPIPE. 程序便能知道对端已经关闭.

PS: Linux下的SIGALRM似乎会每1秒钟往后偏移1毫秒, 但Windows下经过测试完全准时, 不差1毫秒.

忽略SIGPIPE信号的方法
http://hi.baidu.com/greathongjian/blog/item/2f695643091885139213c65a.html
struct sigaction sa;
sa.sa_handler = SIG_IGN;//设定接受到指定信号后的动作为忽略
sa.sa_flags = 0;
if (sigemptyset(&sa.sa_mask) == -1 ||   //初始化信号集为空
sigaction(SIGPIPE, &sa, 0) == -1) {   //屏蔽SIGPIPE信号
perror("failed to ignore SIGPIPE; sigaction");
exit(EXIT_FAILURE);
}

pthread线程里如何屏蔽SIGPIPE异常
hi.baidu.com/ailacy/blog/item/a7eb65f8b8b55707d8f9fdd5.html

在pthread中，可能会遇到Program received signal SIGPIPE, Broken pipe的问题，解决方法是每一个线程启动之前时，先执行下面代码：

#ifndef WIN32
sigset_t signal_mask;
sigemptyset (&signal_mask);
sigaddset (&signal_mask, SIGPIPE);
int rc = pthread_sigmask (SIG_BLOCK, &signal_mask, NULL);
if (rc != 0) {
printf("block sigpipe error\n");
} 
#endif        
当然，这只是多种方法之一~

根据赖半仙的使用经验，只要在main函数一开始就写入上面这段代码，就能屏蔽掉pthread线程中的SIGPIPE

[linux] SIGPIPE信号及其处理
http://hi.baidu.com/mckeyzhang/blog/item/d647f26034eee542eaf8f823.html
在linux下写socket的程序的时候，如果尝试send到一个disconnected socket上，就会让底层抛出一个SIGPIPE信号。
这个信号的缺省处理方法是退出进程，大多数时候这都不是我们期望的。因此我们需要重载这个信号的处理方法。调用以下代码，即可安全的屏蔽SIGPIPE：
struct sigaction sa;
sa.sa_handler = SIG_IGN;
sigaction( SIGPIPE, &sa, 0 );
//======================================================================
SIGPIPEFrom Wikipedia, the free encyclopedia

Jump to: , 

Description	Write on a pipe with no one to read it
Default action	Abnormal termination of the process

SA_SIGINFOmacros

one

On -compliant platforms, SIGPIPE is the  raised when a  attempts to write to a  without a process connected to the other end. The for SIGPIPE is defined in the  signal.h. Symbolic signal names are used because signal numbers can vary across platforms.

Etymology

SIG is a common  for signal names. PIPE refers to the Unix .

Description

 supports the principle of , which allows processes to send data to other processes without the need for creating temporary files. When a pipe is broken, the process writing to it is sent the SIGPIPE signal. The default reaction to this signal for a process is to terminate.

A simple example of piping is the following.

ps l | head

This command, when run on a  machine (including ), returns a list of processes, limited to ten lines.

•  l returns a list of all processes (including those of other users).
•  selects the first ten lines.

When ps has written ten lines, head has received all it needs and exits. ps will receive a SIGPIPE when it tries to write the remaining lines, causing it to terminate as well: It is no use writing data that no one will use. It is also possible that the reading process terminates while reading the data. This will also cause SIGPIPE to be sent to the writing process.

One can ignore SIGPIPE (using, for example, the  ). In this case, all system calls that would cause SIGPIPE to be sent will return -1 and set  to EPIPE.

Uinx 下 Broken pipe 问题

前段时间在处理延时函数时遇到过 "Alarm clock" 信号问题(见我的 "Unix C 延时函数小结")。现在测试中还遇到了 "Broken pipe" 信号问题，同样产生这个信号程序就中止了。 

我的程序产生这个信号的原因是: 
client端通过 pipe 发送信息到server端后，就关闭client端, 这时server端,返回信息给 client 端时就产生Broken pipe 信号了。 

对于产生信号，我们可以在产生信号前利用方法 signal(int signum, sighandler_t handler) 设置信号的处理。如果没有调用此方法，系统就会调用默认处理方法：中止程序，显示提示信息(就是我们经常遇到的问题)。我们可以调用系统的处理方法，也可 以自定义处理方法。 

系统里边定义了三种处理方法： 
1)SIG_DFL    /* Default action */ 
2)SIG_IGN    /* Ignore action */ 
3)SIG_ERR    /* Error return */ 

项目中我调用了 signal(SIGALRM, SIG_IGN) 和 signal(SIGPIPE, SIG_IGN), 这样产生 SIGALAM 和 SIGPIPE 信号时就不会中止程序，直接把这个信号忽略掉。 

自定义处理方法:

void   signal_handle(ing   signo)
{
    //do   something;
}

int   main()
{
    signal(SIGPIPE, signal_handle);
    ......
}