如何監控socket的變化
如何通知socket的變化
1.select:
應用場合:主要面向的是某些使用u n i x作業系統的計算機，它們採用的是b e r k e l e y套接字方案。s e l e c t模型已整合到winsock 1.1中，它使那些想避免在套接字呼叫過程中被無辜「鎖定」的應用程式，採取一種有序的方式，同時進行對多個套接字的管理.
原理: 利用select函式，我們判斷套接字上是否存在資料，或者能否向乙個套接字寫入資料.
2.wsaasyncselect:
應用場合:用於幫助應用程式開發者面向一些早期的16位windows平台（如windowsforworkgroups），適應其「落後」的多工訊息環境。應用程式仍可從這種模型中得到好處，特別是它們用乙個標準的windows例程（常稱為「winproc」），對視窗訊息進行管理的時候。該模型亦得到了microsoftfoundationclass微軟基本類，mfc）物件csocket的採納,
原理:利用wsaasyncselect來處理fd_read、fd_write、fd_accept、fd_connect、fd_close訊息
下面是我的一些理解，不知道是否正確，請指教。
綜合幾種i/o模式，我認為兩種模式來實現伺服器端的程式是比較好的，乙個是最簡單的阻塞模式，乙個是iocp。
說簡單的阻塞模式好，是因為它實現簡單，通常情況下最與伺服器來說，是乙個主線程用來accept使用者的連線，使用者連線來之後，單獨的啟動乙個工作執行緒為其服務，那麼可以在工作執行緒裡按照順序對接收到的資料進行處理，因此實現起來邏輯關係清晰，除了注意一些多執行緒的安全性，比較容易理解。問題是，當遇到大量的併發連線的時候，大量執行緒對資源的占用難以為繼，因此一般需要多使用者的伺服器通常會選擇其他的模式。
那麼要說效能好，可擴充套件，那就一定是iocp。從實現的複雜度來說，iocp也並不是其他幾種模式裡最複雜的。iocp裡面的資料亂序問題大概是需要注意的地方，再有就是要注意多執行緒的安全性。
select模式，應該主要是為了與*nix和早期的win3.1系統相容而使用的，每個處理都要先經過select，效能很難理想
wsaasyncselect模式，由於有每執行緒64object的限制，而且使用視窗的訊息機制，也不會有很好的效能
wsaeventselect，同樣的具有64 event的問題。
那麼後面的這幾個模式到底應該什麼情況下使用呢，是不是用iocp搭建乙個優質的框架，以後很多的伺服器都可以復用了呢？
Socket初學認識 Socket模型
socket實際上代表的是網路通訊的乙個端點，通過socket，使用者所開發的應用程式可以通過網路和其他socket應用程式通訊。socket是網路的i o基礎，也可以將它與unix的管道或者檔案模擬。應用程式需要與遠端主機連線時，應建立乙個socket，之後通過socket與遠端應用程式建立連線，...
socket程式設計模型
wsaasyncselect 最後仍然是這種模型的優缺點，缺點十分明顯，就是無論程式如何都需要乙個視窗來支援，雖然是非同步的通知訊息，但是仍然是在視窗函式裡同步的進行winsock呼叫，這樣就造成了如果有大量的socket在同乙個執行緒的視窗函式裡進行處理，有可能在乙個請求處理過程中又出現了新的so...
Socket模型之重疊I O模型
socket模型之重疊i o模型 這幾天一直在看關於socket程式設計的幾種非同步程式設計，我覺得關於重疊i o模型的一些基本知識，我有必要記下來。在實際的程式設計過程中，我們需要按照下面幾步來編寫我們的socket重疊模型的程式 一 在伺服器端 1 首先初始化socket套接字。由於編寫非同步套...