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

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

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

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

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

　　盡量使用非阻塞模式

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

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

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

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

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

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