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

　　第一：網(wǎng)絡(luò)通訊中的收發(fā)效率

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

　　在網(wǎng)絡(luò)通訊中TCP通訊包括send寫數(shù)據(jù)和recv讀數(shù)據(jù)。

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

　　盡量使用非阻塞模式

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

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

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

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

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

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