關(guān)于pingNotResponseCount

fdream 更新于2015-07-22

我的應(yīng)用場景需要長時間維護不小量的連接，并且需要對client的非正常斷線做出正確的反應(yīng)。
查資料得知TCP協(xié)議在發(fā)送信息后，對方會回復(fù)一個收到，我的抓包結(jié)果也印證了這一點。于是想利用這一點維護pingNotResponseCount，所以client在收到ping后沒有額外回復(fù)任何信息。我一直沒搞清楚TCP協(xié)議中的那個“收到訊息”應(yīng)該怎樣獲得，猜測是fwrite的返回值。但是在實際應(yīng)用時，發(fā)現(xiàn)在TcpConnection.php的send()中，fwrite的返回值與client是否在線沒什么關(guān)系。client明明已經(jīng)非正常斷開，send()發(fā)送ping時的返回值始終是true(也就是說fwrite的返回值始終與$send_buffer的長度相等)。
現(xiàn)在我想請教一下，如何在client不主動回復(fù)server發(fā)來的ping消息，而且不主動發(fā)送ping消息給server的情況下，正常的維護pingNotResponseCount？換句話說，如何獲取client對于收到的包的自動回復(fù)？
對于socket只理解了皮毛，描述不清楚的地方還請大家多多包容。
我的workerman版本是3.1.4；php版本是手動編譯的5.6.7，能開的選項都開了；服務(wù)器是CentOS 7.0 64位

 3425  2 0

2個回答

fdream 2015-07-22

時間太晚了嘛...

暫無評論

walkor 2015-07-22

打賞

查資料得知TCP協(xié)議在發(fā)送信息后，對方會回復(fù)一個收到，我的抓包結(jié)果也印證了這一點。

這個是tcp層面的ack包，是系統(tǒng)內(nèi)核控制的，對于應(yīng)用層是透明的，也就是說應(yīng)用層無法感知到這個ack。

fwrite的返回值與client是否在線沒什么關(guān)系。client明明已經(jīng)非正常斷開，send()發(fā)送ping時的返回值始終是true

應(yīng)用層通過socket接口發(fā)送數(shù)據(jù)給對端，只要數(shù)據(jù)寫到本地socket緩沖區(qū)就返回發(fā)送成功，而緩沖區(qū)的數(shù)據(jù)何時發(fā)送給對端是由操作系統(tǒng)內(nèi)核控制的，并且受網(wǎng)絡(luò)環(huán)境以及對端接收速度影響。如果對端突然斷電或者網(wǎng)絡(luò)切斷等極端情況客戶端是來不及發(fā)送fin包給服務(wù)端，服務(wù)端也就無法立刻得知連接已經(jīng)斷開。這種情況需要應(yīng)用層心跳來解決。

要想及時知道連接是否斷開，一般都要應(yīng)用層心跳來支持，客戶端需要發(fā)送點數(shù)據(jù)告訴服務(wù)端它還在。