今天測試網(wǎng)絡(luò)服務(wù)程序時發(fā)現(xiàn)這樣一個現(xiàn)象：客戶端登錄到服務(wù)器，服務(wù)器如果驗(yàn)證發(fā)現(xiàn)用戶名不存在，就返回客戶端錯誤信息，并斷開與客戶端的連接。但是實(shí)際測試時卻發(fā)現(xiàn)客戶端并沒有接收到用戶名不存在的錯誤信息，并且明明服務(wù)器端關(guān)閉了連接，甚至停止了服務(wù)，但是客戶端仍然顯示是連接狀態(tài)。
調(diào)試，發(fā)現(xiàn)在斷開連接操作之前（即CLOSE SOCKET之前），加斷點(diǎn)或者寫LOG或者SLEEP幾毫秒后，客戶端都可接收到錯誤信息，并成功斷開。于是分析覺得問題可能出在SOCKET的IO處理上，可能SOCKET IO中的數(shù)據(jù)沒有足夠的時間完全發(fā)送，SOCKET就被關(guān)閉了。
仔細(xì)檢查代碼發(fā)現(xiàn)CLOSE SOCKET前做了這樣的操作：
LINGER lingerStruct;
lingerStruct.l_onoff = 1;
lingerStruct.l_linger = 0;
setsockopt( IoSocket, SOL_SOCKET, SO_LINGER, (char *)&lingerStruct, sizeof(lingerStruct) );
CancelIo((HANDLE) IoSocket);
closesocket( IoSocket );
在MSDN中查找setsockeopt關(guān)于LINGER的解釋如下：
Setting the SO_DONTLINGER option prevents blocking on member function Close while waiting for unsent data to be sent. Setting this option is equivalent to setting SO_LINGER with l_onoff set to 0.
若設(shè)置了SO_LINGER，并設(shè)置了零超時間隔，則closesocket()不被阻塞立即執(zhí)行，不論是否有排隊(duì)數(shù)據(jù)未發(fā)送或未被確認(rèn)。這種關(guān)閉方式稱為“強(qiáng)制”或“失效”關(guān)閉，因?yàn)樘捉涌诘奶撾娐妨⒓幢粡?fù)位，且丟失了未發(fā)送的數(shù)據(jù)。在遠(yuǎn)端的recv()調(diào)用將以WSAECONNRESET出錯。
若設(shè)置了SO_LINGER并確定了非零的超時間隔，則closesocket()調(diào)用阻塞進(jìn)程，直到所剩數(shù)據(jù)發(fā)送完畢或超時。這種關(guān)閉稱為“優(yōu)雅的”關(guān)閉。請注意如果套接口置為非阻塞且SO_LINGER設(shè)為非零超時，則closesocket()調(diào)用將以WSAEWOULDBLOCK錯誤返回。
若在一個流類套接口上設(shè)置了SO_DONTLINGER，則closesocket()調(diào)用立即返回。但是，如果可能，排隊(duì)的數(shù)據(jù)將在套接口關(guān)閉前發(fā)送。請注意，在這種情況下WINDOWS套接口實(shí)現(xiàn)將在一段不確定的時間內(nèi)保留套接口以及其他資源，這對于想用所以套接口的應(yīng)用程序來說有一定影響。
簡言之，setsockeopt函數(shù)使用SO_LINGER規(guī)定了斷開SOCKET時處理未發(fā)送完的數(shù)據(jù)的動作。 查詢UNIX文檔中關(guān)于SO_LINGER參數(shù)的解釋更加詳細(xì)： SO_LINGER
此選項(xiàng)指定函數(shù)close對面向連接的協(xié)議如何操作（如TCP）。缺省close操作是立即返回，如果有數(shù)據(jù)殘留在套接口緩沖區(qū)中則系統(tǒng)將試著將這些數(shù)據(jù)發(fā)送給對方。
SO_LINGER選項(xiàng)用來改變此缺省設(shè)置。使用如下結(jié)構(gòu)：
struct linger {
int l_onoff; /* 0 = off, nozero = on */
int l_linger; /* linger time */
};
有下列三種情況：
- l_onoff為0，則該選項(xiàng)關(guān)閉，l_linger的值被忽略，等于缺省情況，close立即返回；
- l_onoff為非0，l_linger為0，則套接口關(guān)閉時TCP夭折連接，TCP將丟棄保留在套接口發(fā)送緩沖區(qū)中的任何數(shù)據(jù)并發(fā)送一個RST給對方，而不是通常的四分組終止序列，這避免了TIME_WAIT狀態(tài)；
- l_onoff 為非0，l_linger為非0，當(dāng)套接口關(guān)閉時內(nèi)核將拖延一段時間（由l_linger決定）。如果套接口緩沖區(qū)中仍殘留數(shù)據(jù)，進(jìn)程將處于睡眠狀態(tài)，直 到（a）所有數(shù)據(jù)發(fā)送完且被對方確認(rèn)，之后進(jìn)行正常的終止序列（描述字訪問計(jì)數(shù)為0）或（b）延遲時間到。此種情況下，應(yīng)用程序檢查close的返回值是 非常重要的，如果在數(shù)據(jù)發(fā)送完并被確認(rèn)前時間到，close將返回EWOULDBLOCK錯誤且套接口發(fā)送緩沖區(qū)中的任何數(shù)據(jù)都丟失。close的成功返 回僅告訴我們發(fā)送的數(shù)據(jù)（和FIN）已由對方TCP確認(rèn)，它并不能告訴我們對方應(yīng)用進(jìn)程是否已讀了數(shù)據(jù)。如果套接口設(shè)為非阻塞的，它將不等待close完 成。
l_linger的單位依賴于實(shí)現(xiàn)，4.4BSD假設(shè)其單位是時鐘滴答（百分之一秒），但Posix.1g規(guī)定單位為秒。 在了解了原理之后，將代碼中的lingerStruct.l_linger 設(shè)置為非零值，問題立即被解決。 這里把這個問題寫出來，希望能夠給大家?guī)睃c(diǎn)啟示。