我正在實現一個服務器,在該服務器中,我偵聽客戶端使用accept套接字調用進行連接。套接字呼叫之間的時間差距,即。 Accept()和recv/send calls
接受發生後,我收到套接字,我等待大約10-15秒,然後再進行第一次recv /發送呼叫。
發送到客戶端的呼叫失敗,errno = 32,即斷開管道。
由於我不控制客戶端,我在接受的套接字中設置了套接字選項* SO_KEEPALIVE *。
const int keepAlive = 1;
acceptsock = accept(sock, (struct sockaddr*)&client_addr, &client_addr_length)
if (setsockopt(acceptsock, SOL_SOCKET, SO_KEEPALIVE, &keepAlive, sizeof(keepAlive)) < 0)
{
print(" SO_KEEPALIVE fails");
}
任何人都可以請告訴可能會出現什麼問題,以及我們如何防止客戶端套接字關閉?
注意 ,我想在這裏補充一點的是,如果沒有時間間隔或接受和發送/ recv的調用之間小於5秒,按預期發生在客戶端服務器通信。
在Linux中,你可以得到errno = 32的錯誤:ENOTCONN也意味着 套接字沒有連接,並且沒有給出目標。請看你在發起send/recv之前所做的系統調用是不是返回錯誤 – Aravind
在你開始調用send()之前,你確認了connect()實際上是否成功,並且通知你一個完整的連接可用?套接字在空閒時間後通常不會自行關閉,對於'SO_KEEPALIVE'來說,10-15秒的時間太短而無法關閉死連接,而10-15秒對於外部防火牆/路由器而言太短以至於無法關閉空閒連接。所以其他事情正在發生。我的猜測是你沒有正確管理你的客戶端套接字。 –
@Aravind和Remy ..是的,connect()成功了,因爲接受阻塞的調用給出了一個有效的accpetsock。此外,在我開始收到錯誤32之前,客戶端也會收到兩次或三次數據。正如我已經提到,如果在接受和發送/接收呼叫之間沒有等待,我不擁有客戶端和客戶端的工作。 – Rajat