5.1.3 非塞模式套接字的優勢和不足

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

要完成這樣的操作，有人使用MSG_PEEK標誌呼叫recv()函式檢視緩衝區中是否有資料可讀。同樣，這種方法也不好。因為該做法對系統造成的開銷是很大的，並且應用程式至少要呼叫recv()函式兩次，才能實際地讀入資料。較好的做法是，使用套接字的“I/O模型”來判斷非阻塞套接字是否可讀可寫。關於套接字的“I/O模型”，將在後續章節中介紹。

非阻塞模式套接字與阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，需要編寫更多的程式碼，以便在每個Windows Sockets API函式呼叫中，對收到的WSAEWOULDBLOCK錯誤進行處理。因此，非阻塞套接字便顯得有些難於使用。

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