linux下recv 、send阻塞、非阻塞區別和用法

非阻塞IO 和阻塞IO:

在網絡編程中對於一個網絡句柄會遇到阻塞IO 和非阻塞IO 的概念, 這裏對於這兩種socket 先做一下說明:
基本概念:

阻塞IO::

socket 的阻塞模式意味着必須要做完IO 操作(包括錯誤)纔會

                     返回。

非阻塞IO::

                     非阻塞模式下無論操作是否完成都會立刻返回,需要通過其他方

                     式來判斷具體操作是否成功。(對於connect,accpet操作,通過select判斷,

                      對於recv,recvfrom,send,sendto通過返回值+錯誤碼來判斷)

IO模式設置:

SOCKET
       對於一個socket 是阻塞模式還是非阻塞模式的處理方法::

       方法::

用fcntl 設置;用F_GETFL獲取flags,用F_SETFL設置flags|O_NONBLOCK;

同時,recv,send 時使用非阻塞的方式讀取和發送消息,即flags設置爲MSG_DONTWAIT

實現

fcntl 函數可以將一個socket 句柄設置成非阻塞模式:


  1       flags = fcntl(sockfd, F_GETFL, 0);                       //獲取文件的flags值。
  2 
  3       fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);   //設置成非阻塞模式;
  4 
  5       flags  = fcntl(sockfd,F_GETFL,0);
  6 
  7       fcntl(sockfd,F_SETFL,flags&~O_NONBLOCK);    //設置成阻塞模式;
  8 
View Code



      並在接收和發送數據時:

     將recv, send 函數的最後有一個flag 參數設置成MSG_DONTWAIT


  1     recv(sockfd, buff, buff_size,MSG_DONTWAIT);     //非阻塞模式的消息發送
  2 
  3      send(scokfd, buff, buff_size, MSG_DONTWAIT);   //非阻塞模式的消息接受
  4 
View Code



普通文件

        對於文件的阻塞模式還是非阻塞模式::

方法1、open時,使用O_NONBLOCK;

方法2、fcntl設置,使用F_SETFL,flags|O_NONBLOCK;

消息隊列

        對於消息隊列消息的發送與接受::

  1     recv(sockfd, buff, buff_size,MSG_DONTWAIT);     //非阻塞模式的消息發送
  2 
  3      send(scokfd, buff, buff_size, MSG_DONTWAIT);   //非阻塞模式的消息接受
  4 
View Code

阻塞與非阻塞讀的區別:  //阻塞和非阻塞的區別在於沒有數據到達的時候是否立刻返回.

讀(read/recv/msgrcv):

讀的本質來說其實不能是讀,在實際中, 具體的接收數據不是由這些調用來進行,是由於系統底層自動完成的。read 也好,recv 也好只負責把數據從底層緩衝copy 到我們指定的位置.

對於讀來說(read, 或者recv) ::

阻塞情況下::

       在阻塞條件下,read/recv/msgrcv的行爲::

       1、如果沒有發現數據在網絡緩衝中會一直等待,

       2、當發現有數據的時候會把數據讀到用戶指定的緩衝區,但是如果這個時候讀到的數據量比較少,比參數中指定的長度要小,read 並不會一直等待下去,而是立刻返回。

read 的原則::是數據在不超過指定的長度的時候有多少讀多少,沒有數據就會一直等待。

所以一般情況下::我們讀取數據都需要採用循環讀的方式讀取數據,因爲一次read 完畢不能保證讀到我們需要長度的數據,

read 完一次需要判斷讀到的數據長度再決定是否還需要再次讀取。

非阻塞情況下::

       在非阻塞的情況下,read 的行爲::

       1、如果發現沒有數據就直接返回,

       2、如果發現有數據那麼也是採用有多少讀多少的進行處理.

             所以::read 完一次需要判斷讀到的數據長度再決定是否還需要再次讀取。

對於讀而言::   阻塞和非阻塞的區別在於沒有數據到達的時候是否立刻返回.
       recv 中有一個MSG_WAITALL 的參數::

       recv(sockfd, buff, buff_size, MSG_WAITALL),
       在正常情況下recv 是會等待直到讀取到buff_size 長度的數據,但是這裏的WAITALL 也只是儘量讀全,在有中斷的情況下recv 還是可能會被打斷,造成沒有讀完指定的buff_size的長度。

所以即使是採用recv + WAITALL 參數還是要考慮是否需要循環讀取的問題,在實驗中對於多數情況下recv (使用了MSG_WAITALL)還是可以讀完buff_size,

       所以相應的性能會比直接read 進行循環讀要好一些。

注意::      //使用MSG_WAITALL時,sockfd必須處於阻塞模式下,否則不起作用。

               //所以MSG_WAITALL不能和MSG_NONBLOCK同時使用。

要注意的是使用MSG_WAITALL的時候,sockfd 必須是處於阻塞模式下,否則WAITALL不能起作用。

阻塞與非阻塞寫的區別:     //
寫(send/write/msgsnd)::

寫的本質也不是進行發送操作,而是把用戶態的數據copy 到系統底層去,然後再由系統進行發送操作,send,write返回成功,只表示數據已經copy 到底層緩衝,而不表示數據已經發出,更不能表示對方端口已經接收到數據.
       對於write(或者send)而言,

阻塞情況下::                 //阻塞情況下,write會將數據發送完。(不過可能被中斷)

       在阻塞的情況下,是會一直等待,直到write 完,全部的數據再返回.這點行爲上與讀操作有所不同。

        原因::

              讀,究其原因主要是讀數據的時候我們並不知道對端到底有沒有數據,數據是在什麼時候結束髮送的,如果一直等待就可能會造成死循環,所以並沒有去進行這方面的處理;

寫,而對於write, 由於需要寫的長度是已知的,所以可以一直再寫,直到寫完.不過問題是write 是可能被打斷嗎,造成write 一次只write 一部分數據, 所以write 的過程還是需要考慮循環write, 只不過多數情況下一次write 調用就可能成功.

非阻塞寫的情況下::     //

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章