當(dāng)服務(wù)器close一個(gè)連接時(shí)，若client端接著發(fā)數(shù)據(jù)。根據(jù)TCP協(xié)議的規(guī)定，會(huì)收到一個(gè)RST響應(yīng)，client再往這個(gè)服務(wù)器發(fā)送數(shù)據(jù)時(shí)，系統(tǒng)會(huì)發(fā)出一個(gè)SIGPIPE信號(hào)給進(jìn)程，告訴進(jìn)程這個(gè)連接已經(jīng)斷開(kāi)了，不要再寫(xiě)了。
根據(jù)信號(hào)的默認(rèn)處理規(guī)則SIGPIPE信號(hào)的默認(rèn)執(zhí)行動(dòng)作是terminate(終止、退出),所以client會(huì)退出。若不想客戶(hù)端退出可以把SIGPIPE設(shè)為SIG_IGN
如: signal(SIGPIPE,SIG_IGN);
這時(shí)SIGPIPE交給了系統(tǒng)處理。
服務(wù)器采用了fork的話(huà)，要收集垃圾進(jìn)程，防止僵尸進(jìn)程的產(chǎn)生，可以這樣處理：
signal(SIGCHLD,SIG_IGN); 交給系統(tǒng)init去回收。
這里子進(jìn)程就不會(huì)產(chǎn)生僵尸進(jìn)程了。
http://www.cublog.cn/u/31357/showart_242605.html
好久沒(méi)做過(guò)C開(kāi)發(fā)了，最近重操舊業(yè)。
聽(tīng)說(shuō)另外一個(gè)項(xiàng)目組socket開(kāi)發(fā)遇到問(wèn)題，發(fā)送端和接受端數(shù)據(jù)大小不一致。建議他們采用writen的重發(fā)機(jī)制，以避免信號(hào)中斷錯(cuò)誤。采用后還是有問(wèn)題。PM讓我?guī)兔ρ芯肯隆?span id="e44a4we" class=Apple-converted-space>
UNP n年以前看過(guò)，很久沒(méi)做過(guò)底層開(kāi)發(fā)，手邊也沒(méi)有UNP vol1這本書(shū)，所以做了個(gè)測(cè)試程序，研究下實(shí)際可能發(fā)生的情況了。
測(cè)試環(huán)境：AS3和redhat 9(缺省沒(méi)有nc)
先下載unp源碼:
wget http://www.unpbook.com/unpv13e.tar.gz
tar xzvf *.tar.gz;
configure;make lib.
然后參考str_cli.c和tcpcli01.c，寫(xiě)了測(cè)試代碼client.c
#include "unp.h"
#define MAXBUF 40960
void processSignal(int signo)
{
printf("Signal is %d\n", signo);
signal(signo, processSignal);
}
void
str_cli(FILE *fp, int sockfd)
{
char sendline[MAXBUF], recvline[MAXBUF];
while (1) {
memset(sendline, 'a', sizeof(sendline));
printf("Begin send %d data\n", MAXBUF);
Writen(sockfd, sendline, sizeof(sendline));
sleep(5);
}
}
int
main(int argc, char **argv)
{
int sockfd;
struct sockaddr_in servaddr;
signal(SIGPIPE, SIG_IGN);
//signal(SIGPIPE, processSignal);
if (argc != 2)
err_quit("usage: tcpcli [port]");
sockfd = Socket(AF_INET, SOCK_STREAM, 0);
bzero(&servaddr, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_port = htons(atoi(argv[1]));
Inet_pton(AF_INET, "127.0.0.1", &servaddr.sin_addr);
Connect(sockfd, (SA *) &servaddr, sizeof(servaddr));
str_cli(stdin, sockfd); /* do it all */
exit(0);
}
為了方便觀察錯(cuò)誤輸出，lib/writen.c也做了修改，加了些日志：
/* include writen */
#include "unp.h"
ssize_t &nbs
|
p; /* Write "n" bytes to a descriptor. */
writen(int fd, const void *vptr, size_t n)
{
size_t nleft;
ssize_t nwritten;
const char *ptr;
ptr = vptr;
nleft = n;
while (nleft > 0) {
printf("Begin Writen %d\n", nleft);
if ( (nwritten = write(fd, ptr, nleft)) <= 0) {
if (nwritten < 0 && errno == EINTR) {
printf("intterupt\n");
nwritten = 0; /* and call write() again */
}
else
return(-1); /* error */
}
nleft -= nwritten;
ptr += nwritten;
printf("Already write %d, left %d, errno=%d\n", nwritten, nleft, errno);
}
return(n);
}
/* end writen */
void
Writen(int fd, void *ptr, size_t nbytes)
{
if (writen(fd, ptr, nbytes) != nbytes)
err_sys("writen error");
}
|
client.c放在tcpclieserv目錄下，修改了Makefile，增加了client.c的編譯目標(biāo)
|
client: client.c
${CC} ${CFLAGS} -o $@ $< ${LIBS}
|
接著就可以開(kāi)始測(cè)試了。
測(cè)試1 忽略SIGPIPE信號(hào)，writen之前，對(duì)方關(guān)閉接受進(jìn)程
本機(jī)服務(wù)端：
nc -l -p 30000
本機(jī)客戶(hù)端:
./client 30000
Begin send 40960 data
Begin Writen 40960
Already write 40960, left 0, errno=0
Begin send 40960 data
Begin Writen 40960
Already write 40960, left 0, errno=0
執(zhí)行到上步停止服務(wù)端,client會(huì)繼續(xù)顯示:
Begin send 40960 data
Begin Writen 40960
writen error: Broken pipe(32)
結(jié)論:可見(jiàn)write之前，對(duì)方socket中斷，發(fā)送端write會(huì)返回-1,errno號(hào)為EPIPE(32)
測(cè)試2 catch SIGPIPE信號(hào)，writen之前，對(duì)方關(guān)閉接受進(jìn)程
修改客戶(hù)端代碼，catch sigpipe信號(hào)
|
//signal(SIGPIPE, SIG_IGN);
signal(SIGPIPE, processSignal);
|
本機(jī)服務(wù)端：
nc -l -p 30000
本機(jī)客戶(hù)端:
make client
./client 30000
Begin send 40960 data
Begin Writen 40960
Already write 40960, left 0, errno=0
Begin send 40960 data
Begin Writen 40960
Already write 40960, left 0, errno=0
執(zhí)行到上步停止服務(wù)端,client會(huì)繼續(xù)顯示:
Begin send 40960 data
Begin Writen 40960
Signal is 13
writen error: Broken pipe(32)
結(jié)論:可見(jiàn)write之前，對(duì)方socket中斷，發(fā)送端write時(shí)，會(huì)先調(diào)用SIGPIPE響應(yīng)函數(shù)，然后write返回-1,errno號(hào)為EPIPE(32)
測(cè)試3 writen過(guò)程中，對(duì)方關(guān)閉接受進(jìn)程
為了方便操作，加大1次write的數(shù)據(jù)量，修改MAXBUF為4096000
本機(jī)服務(wù)端：
nc -l -p 30000
本機(jī)客戶(hù)端:
make client
./client 30000
Begin send 4096000 data
Begin Writen 4096000
執(zhí)行到上步停止服務(wù)端,client會(huì)繼續(xù)顯示:
Already write 589821, left 3506179, errno=0
Begin Writen 3506179
writen error: Connection reset by peer(104)
結(jié)論:可見(jiàn)socket write中，對(duì)方socket中斷，發(fā)送端write會(huì)先返回已經(jīng)發(fā)送的字節(jié)數(shù),再次write時(shí)返回-1,errno號(hào)為ECONNRESET(104)
為什么以上測(cè)試，都是對(duì)方已經(jīng)中斷socket后，發(fā)送端再次write，結(jié)果會(huì)有所不同呢。從后來(lái)找到的UNP5.12,5.13能找到答案
|
The client's call to readline may happen before the server's RST is received by the client, or it may happen after. If the readline happens before the RST is received, as we've shown in our example, the result is an unexpected EOF in the client. But if the RST arrives first, the result is an ECONNRESET ("Connection reset by peer") error return from readline.
|
以上解釋了測(cè)試3的現(xiàn)象，write時(shí)，收到RST.
|
What happens if the client ignores the error return from readline and writes more data to the server? This can happen, for example, if the client needs to perform two writes to the server before reading anything back, with the first write eliciting the RST.
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 process must catch the signal to avoid being involuntarily terminated.
If the process either catches the signal and returns from the signal handler, or ignores the signal, the write operation returns EPIPE.
|
以上解釋了測(cè)試1，2的現(xiàn)象,write一個(gè)已經(jīng)接受到RST的socket，系統(tǒng)內(nèi)核會(huì)發(fā)送SIGPIPE給發(fā)送進(jìn)程，如果進(jìn)程catch/ignore這個(gè)信號(hào)，write都返回EPIPE錯(cuò)誤.
因此,UNP建議應(yīng)用根據(jù)需要處理SIGPIPE信號(hào)，至少不要用系統(tǒng)缺省的處理方式處理這個(gè)信號(hào)，系統(tǒng)缺省的處理方式是退出進(jìn)程，這樣你的應(yīng)用就很難查處處理進(jìn)程為什么退出。
http://blog.csdn.net/shcyd/archive/2006/10/28/1354577.aspx
在Unix系統(tǒng)下，如果send在等待協(xié)議傳送數(shù)據(jù)時(shí)網(wǎng)絡(luò)斷開(kāi)的話(huà)，調(diào)用send的進(jìn)程會(huì)接收到一個(gè)SIGPIPE信號(hào)，進(jìn)程對(duì)該信號(hào)的默認(rèn)處理是進(jìn)程終止。
在Unix系統(tǒng)下，如果recv函數(shù)在等待協(xié)議接收數(shù)據(jù)時(shí)網(wǎng)絡(luò)斷開(kāi)了，那么調(diào)用recv的進(jìn)程會(huì)接收到一個(gè)SIGPIPE信號(hào)，進(jìn)程對(duì)該信號(hào)的默認(rèn)處理是進(jìn)程終止。
處理方法：
在初始化時(shí)調(diào)用signal(SIGPIPE,SIG_IGN)忽略該信號(hào)（只需一次）
其時(shí)send或recv函數(shù)將返回-1，errno為EPIPE，可視情況關(guān)閉socket或其他處理
gdb：
gdb默認(rèn)收到sigpipe時(shí)中斷程序，可調(diào)用handle SIGPIPE nostop print
相關(guān)
(1)SIG_DFL信號(hào)專(zhuān)用的默認(rèn)動(dòng)作:
(a)如果默認(rèn)動(dòng)作是暫停線(xiàn)程，則該線(xiàn)程的執(zhí)行被暫時(shí)掛起。當(dāng)線(xiàn)程暫停期間，發(fā)送給線(xiàn)程的任何附加信號(hào)都不交付，直到該線(xiàn)程開(kāi)始執(zhí)行，但是SIGKILL除外。
(b)把掛起信號(hào)的信號(hào)動(dòng)作設(shè)置成SIG_DFL，且其默認(rèn)動(dòng)作是忽略信號(hào) (SIGCHLD)。
(2)SIG_IGN忽略信號(hào)
(a)該信號(hào)的交付對(duì)線(xiàn)程沒(méi)有影響
(b)系統(tǒng)不允許把SIGKILL或SIGTOP信號(hào)的動(dòng)作設(shè)置為SIG_DFL
(3)指向函數(shù)的指針--捕獲信號(hào)
(a)信號(hào)一經(jīng)交付，接收線(xiàn)程就在指定地址上執(zhí)行信號(hào)捕獲程序。在信號(hào)捕 獲函數(shù)返回后，接受線(xiàn)程必須在被中斷點(diǎn)恢復(fù)執(zhí)行。
(b)用C語(yǔ)言函數(shù)調(diào)用的方法進(jìn)入信號(hào)捕捉程序:
void func (signo)
int signo;
func( )是指定的信號(hào)捕捉函數(shù)，signo是正被交付信號(hào)的編碼
(c)如果SIGFPE,SIGILL或SIGSEGV信號(hào)不是由C標(biāo)準(zhǔn)定義的kill( )或raise( )函數(shù)所生成，則從信號(hào)SIGFPE,SIGILL,SIGSEGV的信號(hào)捕獲函數(shù)正常返回后線(xiàn)程的行為是未定義的。
(d)系統(tǒng)不允許線(xiàn)程捕獲SIGKILL和SIGSTOP信號(hào)。
(e)如果線(xiàn)程為SIGCHLD信號(hào)建立信號(hào)捕獲函數(shù)，而該線(xiàn)程有未被等待的以終止的子線(xiàn)程時(shí)，沒(méi)有規(guī)定是否要生成SIGCHLD信號(hào)來(lái)指明那個(gè)子線(xiàn)程。
每一種信號(hào)都被OSKit給予了一個(gè)符號(hào)名，對(duì)于32位的i386平臺(tái)而言，一個(gè)字32位，因而信號(hào)有32種。下面的表給出了常用的符號(hào)名、描述和它們的信號(hào)值。
符號(hào)名 信號(hào)值 描述 是否符合POSIX
SIGHUP 1 在控制終端上檢測(cè)到掛斷或控制線(xiàn)程死亡 是
SIGINT 2 交互注意信號(hào) 是
SIGQUIT 3 交互中止信號(hào) 是
SIGILL 4 檢測(cè)到非法硬件的指令 是
SIGTRAP 5 從陷阱中回朔 否
SIGABRT 6 異常終止信號(hào) 是
SIGEMT 7 EMT 指令 否
SIGFPE 8 不正確的算術(shù)操作信號(hào) 是
SIGKILL 9 終止信號(hào) 是
SIGBUS 10 總線(xiàn)錯(cuò)誤 否
SIGSEGV 11 檢測(cè)到非法的內(nèi)存調(diào)用 是
SIGSYS 12 系統(tǒng)call的錯(cuò)誤參數(shù) 否
SIGPIPE 13 在無(wú)讀者的管道上寫(xiě) 是
SIGALRM 14 報(bào)時(shí)信號(hào) 是
SIGTERM 15 終止信號(hào) 是
SIGURG 16 IO信道緊急信號(hào) 否
SIGSTOP 17 暫停信號(hào) 是
SIGTSTP 18 交互暫停信號(hào) 是
SIGCONT 19 如果暫停則繼續(xù) 是
SIGCHLD 20 子線(xiàn)程終止或暫?！ ∈?br style="LINE-HEIGHT: normal">SIGTTIN 21 后臺(tái)線(xiàn)程組一成員試圖從控制終端上讀出 是
SIGTTOU 22 后臺(tái)線(xiàn)程組的成員試圖寫(xiě)到控制終端上 是
SIGIO 23 允許I/O信號(hào) 否
SIGXCPU 24 超出CPU時(shí)限 否
SIGXFSZ 25 超出文件大小限制 否
SIGVTALRM 26 虛時(shí)間警報(bào)器 否
SIGPROF 27 側(cè)面時(shí)間警報(bào)器 否
SIGWINCH 28 窗口大小的更改 否
SIGINFO 29 消息請(qǐng)求 否
SIGUSR1 30 保留作為用戶(hù)自定義的信號(hào)1 是
SIGUSR2 31 保留作為用戶(hù)自定義的信號(hào) 是
注意：Linux信號(hào)機(jī)制基本上是從Unix系統(tǒng)中繼承過(guò)來(lái)的。早期Unix系統(tǒng)中的信號(hào)機(jī)制比較簡(jiǎn)單和原始，后來(lái)在實(shí)踐中暴露出一些問(wèn)題，因此，把那些建立在早期機(jī)制上的信號(hào)叫做"不可靠信號(hào)"，信號(hào)值小于SIGRTMIN(Red hat 7.2中，SIGRTMIN=32，SIGRTMAX=63)的信號(hào)都是不可靠信號(hào)。這就是"不可靠信號(hào)"的來(lái)源。它的主要問(wèn)題是：進(jìn)程每次處理信號(hào)后，就將對(duì)信號(hào)的響應(yīng)設(shè)置為默認(rèn)動(dòng)作。在某些情況下，將導(dǎo)致對(duì)信號(hào)的錯(cuò)誤處理；因此，用戶(hù)如果不希望這樣的操作，那么就要在信號(hào)處理函數(shù)結(jié)尾再一次調(diào)用signal()，重新安裝該信號(hào)。
另外，我再做一些補(bǔ)充，產(chǎn)生RST響應(yīng)以至于系統(tǒng)發(fā)出SIGPIPE信號(hào)，應(yīng)該分為兩種情況:
1. 客戶(hù)端到服務(wù)端之間網(wǎng)絡(luò)斷掉，或者服務(wù)端斷電等，物理連接斷掉了，這種情況下客戶(hù)端不會(huì)退出，send函數(shù)正常執(zhí)行，不會(huì)感覺(jué)到自己出錯(cuò)。因?yàn)橛捎谖锢砭W(wǎng)絡(luò)斷開(kāi)，服務(wù)端不會(huì)給客戶(hù)端回應(yīng)錯(cuò)誤消息，沒(méi)有RST響應(yīng)，自然也不會(huì)產(chǎn)生SIGPIPE信號(hào)。但是當(dāng)服務(wù)端再恢復(fù)正常的時(shí)候，對(duì)客戶(hù)端send來(lái)的消息會(huì)產(chǎn)生RST響應(yīng)，客戶(hù)端就收到SIGPIPE信號(hào)了，程序退出，但是這時(shí)send函數(shù)是能夠返回 -1的。可以進(jìn)行異常處理。
2.客戶(hù)端到服務(wù)端的網(wǎng)絡(luò)能通，服務(wù)程序掛掉，客戶(hù)端程序會(huì)馬上退出，因?yàn)榉?wù)端能正常返回錯(cuò)誤消息，客戶(hù)端收到，SIGPIPE信號(hào)就產(chǎn)生了。不過(guò)我不確定此時(shí)服務(wù)端返回是的RST響應(yīng)，抓包來(lái)看沒(méi)有RST標(biāo)志。水平有限，只寫(xiě)到這了。
文章出處：http://www.diybl.com/course/6_system/linux/Linuxjs/20081020/150832.html