作者: famdestiny ?時(shí)間: 2008-09-18 16:59:00
1、在accept函數(shù)返回前連接夭折
這種情況發(fā)生在TCP 3次握手剛好完成，服務(wù)器TCP將連接放入到已經(jīng)建立好連接隊(duì)列中，此時(shí)客戶端給一個(gè)RST,接下來accept返回，不過這時(shí)accept返回的是ECONNECTABORT錯(cuò)誤.這不是一個(gè)致命錯(cuò)誤。
2、服務(wù)器進(jìn)程終止
過程如下:
a、kill掉服務(wù)進(jìn)程，作為進(jìn)程善后處理的部分，所有打開的文件描述符被關(guān)閉，這導(dǎo)致服務(wù)端TCP(注意"服務(wù)端"和"服務(wù)端TCP"是不同概念)發(fā)送FIN給客戶端，客戶端TCP響應(yīng)以ACK。
b、客戶端此時(shí)正阻塞在scanf函數(shù)(基于上篇中提到的客戶端模型)，這導(dǎo)致客戶端不知道服務(wù)端TCP已經(jīng)關(guān)閉連接。
c、客戶端在scanf返回后調(diào)用write向服務(wù)端發(fā)數(shù)據(jù)，由于服務(wù)端已經(jīng)被kill掉，所以服務(wù)端TCP會(huì)發(fā)送一個(gè)RST給客戶端TCP.
d、客戶端在發(fā)送完數(shù)據(jù)后立即調(diào)用read讀取數(shù)據(jù)，由于有第一步的FIN,read立即返回0(表示EOF),然而客戶端希望的是收到剛才發(fā)送的數(shù)據(jù)而不是EOF。如果客戶端接著往服務(wù)端發(fā)數(shù)據(jù)，將誘發(fā)服務(wù)端TCP向服務(wù)端發(fā)送SIGPIPE信號(hào)，因?yàn)橄蚪邮盏絉ST的套接口寫數(shù)據(jù)都會(huì)收到此信號(hào).
問題的本質(zhì)在于客戶端同時(shí)處理兩個(gè)描述字--套接口和用戶輸入，程序被單純地阻塞在一個(gè)源上了。這個(gè)問題可以通過1、設(shè)置非阻塞模式。2、采用select以及epoll處理。
3、服務(wù)器主機(jī)崩潰
在客戶TCP發(fā)送數(shù)據(jù)后，由于接收不到ACK,它將試圖一直重傳，直到最后放棄，并返回給客戶進(jìn)程一個(gè)出錯(cuò)信息。ETIMEOUT表示沒有相應(yīng)，EHOSTUNREACH表示路由器判定主機(jī)不可達(dá)。
4、服務(wù)器崩潰后重啟
由于服務(wù)端TCP丟失了以前的連接信息，這將導(dǎo)致服務(wù)端發(fā)送一個(gè)RST,而此時(shí)客戶端阻塞在read函數(shù)，這將導(dǎo)致返回一個(gè)ECONNECTRESET錯(cuò)誤.
5、服務(wù)器關(guān)機(jī)
服務(wù)器關(guān)機(jī)時(shí)init進(jìn)程會(huì)先發(fā)送SIGTERM(此信號(hào)可捕獲)給所有進(jìn)程，再過一段時(shí)間發(fā)送SIGKILL(次信號(hào)不可捕獲)給仍然在運(yùn)行的程序，這時(shí)就和服務(wù)器進(jìn)程終止一樣了。
?