數字視頻監(jiān)控應用中，必須用到網絡通訊，就網絡通訊需要注意的幾個問題在這里表達下自己的看法。

　　第一：網絡通訊中的收發(fā)效率

　　視頻監(jiān)控中需要傳輸視頻流，視頻流是比較大的數據，所以對于網絡通訊的中的收發(fā)效率提高是比較關鍵的。

　　在網絡通訊中TCP通訊包括send寫數據和recv讀數據。

　　讀本質來說其實不能是讀，在實際中，具體的接收數據不是由這些調用來進行，是由于系統(tǒng)底層自動完成的，read也好，recv也好只負責把數據從底層緩沖copy到我們指定的位置.對于讀來說(read，或者recv)，在阻塞條件下如果沒有發(fā)現數據在網絡緩沖中會一直等待，當發(fā)現有數據的時候會把數據讀到用戶指定的緩沖區(qū)，但是如果這個時候讀到的數據量比較少，比參數中指定的長度要小，read并不會一直等待下去，而是立刻返回。read的原則是數據在不超過指定的長度的時候有多少讀多少，沒有數據就會一直等待。所以一般情況下我們讀取數據都需要采用循環(huán)讀的方式讀取數據，一次read完畢不能保證讀到我們需要長度的數據，read完一次需要判斷讀到的數據長度再決定是否還需要再次讀取。在非阻塞的情況下，read的行為是如果發(fā)現沒有數據就直接返回，如果發(fā)現有數據那么也是采用有多少讀多少的進行處理.對于讀而言，阻塞和非阻塞的區(qū)別在于沒有數據到達的時候是否立刻返回.recv中有一個MSG_WAITALL的參數recv(sockfd，buff，buff_size，MSG_WAITALL)，在正常情況下recv是會等待直到讀取到buff_size長度的數據，但是這里的WAITALL也只是盡量讀全，在有中斷的情況下recv還是可能會被打斷，造成沒有讀完指定的buff_size的長度。所以即使是采用recv+WAITALL參數還是要考慮是否需要循環(huán)讀取的問題，在實驗中對于多數情況下recv還是可以讀完buff_size，所以相應的性能會比直接read進行循環(huán)讀要好一些。不過要注意的是這個時候的sockfd必須是處于阻塞模式下，否則WAITALL不能起作用。

　　寫的本質也不是進行發(fā)送操作，而是把用戶態(tài)的數據copy到系統(tǒng)底層去，然后再由系統(tǒng)進行發(fā)送操作，返回成功只表示數據已經copy到底層緩沖，而不表示數據以及發(fā)出，更不能表示對端已經接收到數據.對于write(或者send)而言，在阻塞的情況是會一直等待直到write完全部的數據再返回.這點行為上與讀操作有所不同，究其原因主要是讀數據的時候我們并不知道對端到底有沒有數據，數據是在什么時候結束發(fā)送的，如果一直等待就可能會造成死循環(huán)，所以并沒有去進行這方面的處理;而對于write，由于需要寫的長度是已知的，所以可以一直再寫，直到寫完.不過問題是write是可能被打斷造成write一次只write一部分數據，所以write的過程還是需要考慮循環(huán)write，只不過多數情況下一次write調用就可能成功。

　　非阻塞寫的情況下，是采用可以寫多少就寫多少的策略.與讀不一樣的地方在于，有多少讀多少是由網絡發(fā)送的那一端是否有數據傳輸到為標準，但是對于可以寫多少是由本地的網絡堵塞情況為標準的，在網絡阻塞嚴重的時候，網絡層沒有足夠的內存來進行寫操作，這時候就會出現寫不成功的情況，阻塞情況下會盡可能(有可能被中斷)等待到數據全部發(fā)送完畢，對于非阻塞的情況就是一次寫多少算多少，沒有中斷的情況下也還是會出現write到一部分的情況.

　　所以基于socket讀和寫的本質，我們可以得出結論，不是每次收發(fā)越大越好，也不是每次收發(fā)越小越好，需要根據網絡的實際情況得出這樣一個臨界值。

　　第二：盡量使用非阻塞模式

　　在這里有必要對阻塞的概念作一解釋：一個socket可以處于"阻塞模式"或"非阻塞模式"，當一個套接字處于阻塞模式(即同步操作)時，它的阻塞函數直到操作完成才會返回控制權，之所以稱為阻塞是因為此套接字的阻塞函數在完成操作返回之前什么也不能做。如果一個socket處于非阻塞模式(即異步操作)，則會被調用函數立即返回?？梢杂肎etLastError成員函數查詢最后的錯誤。微軟建議盡量使用非阻塞模式，通過網絡事件的發(fā)生而通知應用程序進行相應的處理。

　　在視頻數據傳輸部分為了不影響其他的業(yè)務，所以建議都使用線程在線程中用非阻塞模式的socket來收發(fā)數據，這樣既不會影響其他業(yè)務的正常運作，還不會導致如果是阻塞模式下阻塞情況下線程退出不及時的問題。