1、在accept函式返回前連線夭折
這種情況發生在tcp 3次握手剛好完成，伺服器tcp將連線放入到已經建立好連線佇列中，此時客戶端給乙個rst,接下來accept返回，不過這時accept返回的是econnectabort錯誤.這不是乙個致命錯誤。2、伺服器程序終止
過程如下:3、伺服器主機崩潰a、kill掉服務程序，作為程序善後處理的部分，所有開啟的檔案描述符被關閉，這導致服務端tcp(注意"服務端"和"服務端tcp"是不同概念)傳送fin給客戶端，客戶端tcp響應以ack。
b、客戶端此時正阻塞在scanf函式(基於上篇中提到的客戶端模型)，這導致客戶端不知道服務端tcp已經關閉連線。
c、客戶端在scanf返回後呼叫write向服務端發資料，由於服務端已經被kill掉，所以服務端tcp會傳送乙個rst給客戶端tcp.
d、客戶端在傳送完資料後立即呼叫read讀取資料，由於有第一步的fin,read立即返回0(表示eof),然而客戶端希望的是收到剛才傳送的資料而不是eof。如果客戶端接著往服務端發資料，將誘發服務端tcp向服務端傳送sigpipe訊號，因為向接收到rst的套介面寫資料都會收到此訊號.
問題的本質在於客戶端同時處理兩個描述字--套介面和使用者輸入，程式被單純地阻塞在乙個源上了。這個問題可以通過1、設定非阻塞模式。2、採用select以及epoll處理。
在客戶tcp傳送資料後，由於接收不到ack,它將試圖一直重傳，直到最後放棄，並返回給客戶程序乙個出錯資訊。etimeout表示沒有相應，ehostunreach表示路由器判定主機不可達。4、伺服器崩潰後重啟
由於服務端tcp丟失了以前的連線資訊，這將導致服務端傳送乙個rst,而此時客戶端阻塞在read函式，這將導致返回乙個econnectreset錯誤.5、伺服器關機
伺服器關機時init程序會先傳送sigterm(此訊號可捕獲)給所有程序，再過一段時間傳送sigkill(次訊號不可捕獲)給仍然在執行的程式，這時就和伺服器程序終止一樣了。
UNIX網路程式設計 併發伺服器（多程序）
以下程式的源 均是unix網路程式設計上的例子程式。intro daytimetcpsrv1.c include unp.h include include apueerror.h int main int argc,char argv tcp一般採用併發伺服器。當服務乙個客戶請求可能花費較長時間時...
UNIX網路程式設計 伺服器高效併發模式
半同步 半非同步模式 在併發模式下，同步和非同步的概念與i o同步非同步的概念有所不同，這裡的同步是指程式按照 的順序執行，而非同步指的是程式的執行需要系統事件來驅動，比如訊號 中斷等。非同步執行緒效率高，但編寫相對複雜，難於調式，而同步執行緒剛好相反，邏輯簡單，但效率較差。半同步 半非同步模式結合...
Unix網路程式設計伺服器設計方式之二
此方式首先伺服器端建立乙個監聽，並阻塞至accetp處，當乙個客戶端進行連線時，accept函式並啟用並返回，此時用fork函式建立乙個子程序，由子程序執行客戶請求處理程式，而父程序繼續監聽，等待其他的客戶端。此方式會建立很多的程序，程序個數受具體的作業系統的限制。這種併發伺服器的缺點在於建立乙個子...