最近項目上使用Socket接收單邊機傳送過來的h264裸流,這個小小的需求結(jié)果得花非常多的時間測試其穩(wěn)定性。以下是在開發(fā)過程中解決的一點心得。
信號
使用bsd sockets得需要注意處理SIGPIPE信號,這是一個不可恢復(fù)的系統(tǒng)信號,如果不做處理程序會直接crash。而我們需要給用戶一個友好的提示自定義協(xié)議
h264數(shù)據(jù)是一個連續(xù)的IO流,所以雙方都需定義一個協(xié)議指導(dǎo)客戶端如果接收數(shù)據(jù)。協(xié)議包含frame的大小, i/p 的標記位等等業(yè)務(wù)相關(guān)信息。
在實際測試途中,協(xié)議頭并沒有如愿接收正確的數(shù)據(jù)。比如期望的結(jié)果是 01 07 09 10, 但是客戶端收到的是 01 00 00 00 ,后面的數(shù)據(jù)都被置0了, 造成接收幀數(shù)據(jù)的時候?qū)R錯誤。
最后的解決辦法就是盡量精簡協(xié)議頭長度,只保留幀長度等關(guān)鍵信息。另外,在獲取幀數(shù)據(jù)的時候查找 h264 00 00 00 01 的分隔符。盡量保證數(shù)據(jù)的穩(wěn)定性。超時
使用socket一個不穩(wěn)定的地方就是,如果單邊機出現(xiàn)一些不可預(yù)測是耗時操作影響發(fā)送速度,recv會長時間的阻塞。這時就留下一個難題,是設(shè)置足夠長的時間等待還是規(guī)定時間關(guān)閉連接。給方便權(quán)衡之下選擇使用默認超時。給socket一個‘復(fù)活’的機會