在資料驅動架構公升級這一主題下, 更好地統計異常斷線率
服務是學生老師一對一連線, 多數情況下為學生的網路條件較差, 因此此處假定老師的網路為正常.
老師裝置為 ipad, 系統為 ios 9.3.5, 網路 wifi: iyunxiao
學生 android 裝置為 一加6, 系統為 android 9, ios 裝置為 ipad mini, 系統為 ios 11.3.1, windows 系統為 windows 10, 網路 wifi: ai-yunxiao
ios 程式模擬的異常為下標越界, 導致程式退出. (這是大多數的出現的異常情況)
android 程式模擬的異常為程式跳入主介面, 報錯顯示程式報錯. (android 各裝置顯示均不相同, 無法很好的**異常出現時的到底發生什麼情況)
windows 程式模擬的異常, 是程式卡住. 也不報錯什麼也不顯示, 只是無法點選關閉按鈕關閉頁面.
學生端程式在正常執行的情況下, 斷開wifi, 不殺掉客戶端程式
學生端程式在正常執行的情況下, 殺掉客戶端程式, 不斷開 wifi
學生端程式在正常執行的情況下, 先殺掉客戶端程式, 再斷開 wifi
學生端程式在正常執行的情況下, 先斷開 wifi, 再殺掉客戶端程式
學生端程式在進入課堂後, 30s後客戶端突然奔潰
過程1ios端: 服務端異常, i/o timeout, session: 7211938
android: 服務端異常, i/o timeout, session: 7211968
windows: 服務端異常, i/o timeout, session: 7211986
過程2ios端:
在老師裝置上顯示完指令的時候, 殺掉客戶端, 服務端異常, eof, session: 7211947 7211948
在老師裝置上還有未顯示完指令的時候, 殺掉客戶端, 服務端異常, connection reset by peer, session: 7211946 7211949
android端:
無論有無顯示完的指令, 都是服務端異常服務端異常, eof, session: 7211972
windows 端:
服務端異常, connection reset by peer, session: 7211990
過程3ios端: 無論有無顯示完的指令都是服務端異常, i/o timeout, session: 7211943
android端:
在老師裝置上顯示完指令的時候, 殺掉客戶端, 服務端異常, eof, session: 7211975
在老師裝置上還有未顯示完指令的時候, 殺掉客戶端, 有時候, 服務端異常, eof, session: 7211974, 有時候, 服務端異常, connection reset by peer, session: 7211976 7211977
windows 端:
服務端異常, connection reset by peer, session: 7211991
過程4ios端: 服務端異常, i/o timeout, session: 7211945
android: 無論有無顯示完的指令, 都是服務端異常, i/o timeout, session: 7211980 7211981
windows 端: 服務端異常, i/o timeout, session: 7211992
過程5ios端: 無論有無顯示完的指令, 都是服務端異常, connection reset by peer, session: 7211954
android端：無論有無顯示完的指令, 都是服務端異常服務端異常, eof, session: 7211982 7211983
只要三端先斷開 wifi, 無論殺掉客戶端與否, 服務端都會出現 i/o timeout 的 tcp 錯誤.
windows 在其他的異常情況下, 收到的都是connection reset by peer的異常, 與參考文件中的結果一致, 參考文件中的客戶端也是使用 windows 平台.
ios 在客戶端被殺掉的情況下, 如果 wifi 被斷, 會收到 i/o timeout 的 tcp 錯誤, 跟過程1、過程4相似. 但是 wifi 如果不被斷, 當殺掉程式的那一刻, 如果還有 tcp 資料傳輸, 則是 connection reset by peer, 否則是 eof
android 的情況比較複雜, 在客戶端被殺掉的情況下, 如果 wifi 被斷, 其會出現 eof 以及connection reset by peer. 如果沒被斷, 則只會出現 eof 的情況.
從三端出現 tcp error 型別來推測異常發生的情景:
android:
eof 的出現表明客戶端的程式奔潰, 無響應, 還有可能是程式被使用者自己殺掉, 但是這種情況正常情況下, 使用者不會無緣無故殺掉正在上課的程式.
i/o timeout 的出現表明客戶端那塊的網路出現異常, 路由器無網路, 進入長隧道等, 即使用者網路消失了.
connection reset by peer 的出現也是出現在網路出現問題的時候.
ios:
eof: 發生在程式退出, 被使用者殺掉
i/o timeout 的出現表明客戶端那塊的網路出現異常, 路由器無網路, 進入長隧道等, 即使用者網路消失了.
connection reset by peer 出現在程式奔潰的
windows:
i/o timeout 的情況同ios、android.
connection reset by peer 的情況發生在程式被殺等除網路發生的情況.
eof 的異常未發生.
broken pipe 在測試中未發生. 在正式環境上有出現, 但是也相對較少. 其出現常常伴隨有connection reset by peer的異常
tcp異常關閉之總結
tcp異常關閉研究分析
深入研究分析tcp的異常關閉
TCP斷線重連
struct sockaddr in tempsadd tempsadd.sin family af inet tempsadd.sin port htons m serverport tempsadd.sin addr.s addr inet addr m serverip.c str if 1 ...
監測CentOS下TCP斷線
tcp正常的斷開，通訊雙方 服務端和客戶端 都是能知道的。但是非正常的斷開，比如直接拔掉了網線，就只能靠如下兩種方法，實現短時間內的檢測。一 心跳包機制 心跳包機制，是網遊設計中的常用機制。從使用者層面，自己發包去判斷對方連線狀態。可以根據情況，很靈活的使用。比如，20秒傳送乙個最小的資料報 也可以...
監測CentOS下TCP斷線
tcp正常的斷開，通訊雙方 服務端和客戶端 都是能知道的。但是非正常的斷開，比如直接拔掉了網線，就只能靠如下兩種方法，實現短時間內的檢測。一 心跳包機制 心跳包機制，是網遊設計中的常用機制。從使用者層面，自己發包去判斷對方連線狀態。可以根據情況，很靈活的使用。比如，20秒傳送乙個最小的資料報 也可以...