Socket的阻塞模式和非阻塞模式

2021-05-25 05:50:28 字數 2913 閱讀 6721

阻塞模式

windows套接字在阻塞和非阻塞兩種模式下執行i/o操作。在阻塞模式下,在i/o操作完成前,執行的操作函式一直等候而不會立即返回,該函式所在的執行緒會阻塞在這裡。相反,在非阻塞模式下,套接字函式會立即返回,而不管i/o是否完成,該函式所在的執行緒會繼續執行。

在阻塞模式的套接字上,呼叫任何乙個windows sockets api都會耗費不確定的等待時間。圖所示,在呼叫recv()函式時,發生在核心中等待資料和複製資料的過程。

當呼叫recv()函式時,系統首先查是否有準備好的資料。如果資料沒有準備好,那麼系統就處於等待狀態。當資料準備好後,將資料從系統緩衝區複製到使用者空間,然後該函式返回。在套接應用程式中,當呼叫recv()函式時,未必使用者空間就已經存在資料,那麼此時recv()函式就會處於等待狀態。

windows套接字程式使用「生產者-消費者」模式來解決上述問題。在程式中,「生產者」讀入資料,「消費者」根據需求對讀入資料進行處理。通常「生產者」和「消費者」存在於兩個執行緒中,當「生產者」完成讀入資料時,使用執行緒同步機制,例如設定乙個事件通知「消費者」,「消費者」接收到這個事件後對讀入的資料進行處理。

當使用socket()函式和wsasocket()函式建立套接字時,預設的套接字都是阻塞的。這意味著當呼叫windows sockets api不能立即完成時,執行緒處於等待狀態,直到操作完成。

並不是所有windows sockets api以阻塞套接字為引數呼叫都會發生阻塞。例如,以阻塞模式的套接字為引數呼叫bind()、listen()函式時,函式會立即返回。將可能阻塞套接字的windows sockets api呼叫分為以下四種:

1.輸入操作

recv()、recvfrom()、wsarecv()和wsarecvfrom()函式。以阻塞套接字為引數呼叫該函式接收資料。如果此時套接字緩衝區內沒有資料可讀,則呼叫執行緒在資料到來前一直睡眠。

2.輸出操作

send()、sendto()、wsasend()和wsasendto()函式。以阻塞套接字為引數呼叫該函式傳送資料。如果套接字緩衝區沒有可用空間,執行緒會一直睡眠,直到有空間。

3.接受連線

accept()和wsaacept()函式。以阻塞套接字為引數呼叫該函式,等待接受對方的連線請求。如果此時沒有連線請求,執行緒就會進入睡眠狀態。

4.外出連線

connect()和wsaconnect()函式。對於tcp連線,客戶端以阻塞套接字為引數,呼叫該函式向伺服器發起連線。該函式在收到伺服器的應答前,不會返回。這意味著tcp連線總會等待至少到伺服器的一次往返時間。

使用阻塞模式的套接字,開發網路程式比較簡單,容易實現。當希望能夠立即傳送和接收資料,且處理的套接字數量比較少的情況下,使用阻塞模式來開發網路程式比較合適。

阻塞模式套接字的不足表現為,在大量建立好的套接字執行緒之間進行通訊時比較困難。當使用「生產者-消費者」模型開發網路程式時,為每個套接字都分別分配乙個讀執行緒、乙個處理資料線程和乙個用於同步的事件,那麼這樣無疑加大系統的開銷。其最大的缺點是當希望同時處理大量套接字時,將無從下手,其擴充套件性很差。

非阻塞模式

把套接字設定為非阻塞模式,即通知系統核心:在呼叫windows sockets api時,不要讓執行緒睡眠,而應該讓函式立即返回。在返回時,該函式返回乙個錯誤**。圖所示,乙個非阻塞模式套接字多次呼叫recv()函式的過程。前三次呼叫recv()函式時,核心資料還沒有準備好。因此,該函式立即返回wsaewouldblock錯誤**。第四次呼叫recv()函式時,資料已經準備好,被複製到應用程式的緩衝區中,recv()函式返回成功指示,應用程式開始處理資料。

當使用socket()函式和wsasocket()函式建立套接字時,預設都是阻塞的。在建立套接字之後,通過呼叫ioctlsocket()函式,將該套接字設定為非阻塞模式。linux下的函式是:fcntl().

套接字設定為非阻塞模式後,在呼叫windows sockets api函式時,呼叫函式會立即返回。大多數情況下,這些函式呼叫都會呼叫「失敗」,並返回wsaewouldblock錯誤**。說明請求的操作在呼叫期間內沒有時間完成。通常,應用程式需要重複呼叫該函式,直到獲得成功返回**。

需要說明的是並非所有的windows sockets api在非阻塞模式下呼叫,都會返回wsaewouldblock錯誤。例如,以非阻塞模式的套接字為引數呼叫bind()函式時,就不會返回該錯誤**。當然,在呼叫wsastartup()函式時更不會返回該錯誤**,因為該函式是應用程式第一呼叫的函式,當然不會返回這樣的錯誤**。

要將套接字設定為非阻塞模式,除了使用ioctlsocket()函式之外,還可以使用wsaasyncselect()和wsaeventselect()函式。當呼叫該函式時,套接字會自動地設定為非阻塞方式。

由於使用非阻塞套接字在呼叫函式時,會經常返回wsaewouldblock錯誤。所以在任何時候,都應仔細檢查返回**並作好對「失敗」的準備。應用程式連續不斷地呼叫這個函式,直到它返回成功指示為止。上面的程式清單中,在while迴圈體內不斷地呼叫recv()函式,以讀入1024個位元組的資料。這種做法很浪費系統資源。

要完成這樣的操作,有人使用msg_peek標誌呼叫recv()函式檢視緩衝區中是否有資料可讀。同樣,這種方法也不好。因為該做法對系統造成的開銷是很大的,並且應用程式至少要呼叫recv()函式兩次,才能實際地讀入資料。較好的做法是,使用套接字的「i/o模型」來判斷非阻塞套接字是否可讀可寫。

非阻塞模式套接字與阻塞模式套接字相比,不容易使用。使用非阻塞模式套接字,需要編寫更多的**,以便在每個windows sockets api函式呼叫中,對收到的wsaewouldblock錯誤進行處理。因此,非阻塞套接字便顯得有些難於使用。

但是,非阻塞套接字在控制建立的多個連線,在資料的收發量不均,時間不定時,明顯具有優勢。這種套接字在使用上存在一定難度,但只要排除了這些困難,它在功能上還是非常強大的。通常情況下,可考慮使用套接字的「i/o模型」,它有助於應用程式通過非同步方式,同時對乙個或多個套接字的通訊加以管理。

Socket 阻塞模式和非阻塞模式

阻塞i o模型 簡介 程序會 一直阻塞 直到資料拷貝 完成 應用程式呼叫乙個io函式,導致應用程式阻塞,等待資料準備好。如果資料沒有準備好,一直等待 資料準備好了,從核心拷貝到使用者空間,io函式返回成功指示。阻塞i o模型圖 在呼叫recv recvfrom 函式時,發生在核心中等待資料和複製資料...

Socket的阻塞模式和非阻塞模式

阻塞模式 windows套接字在阻塞和非阻塞兩種模式下執行i o操作。在阻塞模式下,在i o操作完成前,執行的操作函式一直等候而不會立即返回,該函式所在的執行緒會阻塞在這裡。相反,在非阻塞模式下,套接字函式會立即返回,而不管i o是否完成,該函式所在的執行緒會繼續執行。在阻塞模式的套接字上,呼叫任何...

Socket的阻塞模式和非阻塞模式

阻塞模式 windows套接字在阻塞和非阻塞兩種模式下執行i o操作。在阻塞模式下,在i o操作完成前,執行的操作函式一直等候而不會立即返回,該函式所在的執行緒會阻塞在這裡。相反,在非阻塞模式下,套接字函式會立即返回,而不管i o是否完成,該函式所在的執行緒會繼續執行。在阻塞模式的套接字上,呼叫任何...