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

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

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

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

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

　　盡量使用非阻塞模式

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

　　非阻塞寫的情況下，是采用可以寫多少就寫多少的策略.與讀不一樣的地方在于，有多少讀多少是由網絡發(fā)送的那一端是否有數(shù)據傳輸?shù)綖闃藴剩菍τ诳梢詫懚嗌偈怯杀镜氐木W絡堵塞情況為標準的，在網絡阻塞嚴重的時候，網絡層沒有足夠的內存來進行寫操作，這時候就會出現(xiàn)寫不成功的情況，阻塞情況下會盡可能(有可能被中斷)等待到數(shù)據全部發(fā)送完畢，對于非阻塞的情況就是一次寫多少算多少，沒有中斷的情況下也還是會出現(xiàn)write到一部分的情況.

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

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

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

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