一般來講， 在服務器上，如果有足夠的資源，Winsock server，理論上可以支持成千的并發連接。而現實是，我們沒有足夠的資源可供使用，分配。本文主要來討論一下內存資源之于Winsock server開發的重要性。
一）基本概念。
-> Pages,Locked Pages.
        在現代操作系統中，內存管理會把主存(RAM)分成Pages來管理。 Paging(或者swapping）指的是主存與外存之間以Page為單位進行數據的交換。Locked Pages指的是被鎖定在主存中的內存頁，以保證一些內核組件,driver可以訪問到它們。windows一定會保證一定數量的可交換的內存空間，防止一些非法程序鎖定所有的物理內存，而致使系統崩潰。在windows NT, windows 2000上，可鎖定的內存總的大小上限大概是物理內存的1/8(當然對于程序的開發人員，不應該對這個值進行任何的假設，這個值可能會隨著操作系統本版的變化而變化)。在Winsock應用開發過程中，以overlapped方式讀寫IO操作，將會導致內存被鎖定。
-> working set
        在程序開始運行，并達到其穩定的運行狀態（主要指的是其對內存的使用），在這個狀態下，程序使用內存的數量一般小于其需要使用內存的總量。這樣一個穩定的運行狀態，我們可以稱為working set: 被該程序頻繁訪問的內存頁的集合。在windows上，你可以使用SetWorkingSetSize Win32 API來增加程序使用物理內存的數量。
-> non-paged pool
       不可交換的內存。這主要指以non-paged的方式分配的內存，這些內存就像locked pages一樣，是從來不會被交換出去的，用來存放一些由內核組件,driver訪問的信息。 在Winsock應用開發過程中，以下的操作可能導致分配non-paged內存。
1) 調用系統一些系統的API，例如打開文件，create socket，等，都會導致從non-paged pool分配內存。
2) 一些driver可以顯式地從該區域分配內存。
二) Winsock server上Locked Pages使用。
        我們提到過，任何的overlapped IO操作，都會導致鎖定內存頁。這些內存頁一旦被locked,就不會被交換出去。我們知道，windows操作系統對最大的可鎖定內存頁做了一個上限，如果超出這個上限，overlapped IO調用將會導致WSAENOBUFS錯誤。
        考慮下面的情況，如果server在每個連接上會發出很多的overlapped receives操作，那么，隨著連接數目的增多，很明顯，被鎖定的內存數量很有可能達到上限而導致WSAENOBUFS錯誤。在這種情況下，如果服務器預期會處理大數量的客戶端連接，則需要服務器在每個連接上發出zero-byte buffer的overlapped接收請求(這種情況下，因為the size of buffer is zero,所以沒有任何內存被鎖定)，一旦overlapped接收操作完成，server可以以non-blocking方式執行receive操作，以取得所有緩存在so_rcvbuf中的數據，直到返回WSAEWOULDBLOCK為止。
        另外需要注意的是，windows在page的邊界上對內存進行鎖定，在x86平臺上，它是4kb的整數倍。所以，假如你post了一個1 KB buffer，而系統真實鎖定的是4 KB 的大小，為了避免這樣的浪費，盡量用4kb的整數做overlapped  IO操作。
三) Winsock server上non-paged pool使用。
        同Locked Pages限制一樣，windows對non-paged pool也有一個最大的限制。并且，當你的應用出現這個問題的時候，超出它的最大限制數，情況要遠比Locked Pages復雜。這種情況下，后果是不確定的，有可能你的Winsock調用返回WSAENOBUFS錯誤，也有可能，在系統中，一個和你的應用毫無關聯的driver由于申請不到non-paged內存而致使system crash。而這樣的災難，是沒法恢復的。
        考慮一個具體的例子：我們假設在windows2000上,系統有1 GB內存。這樣的配置下，windows大概會預留1/4的空間用作non-paged pool(同樣，對于程序的開發人員，不應該對這個值進行任何的假設)，即：256MB。這樣的配置下，保守估計，我們的Winsock server能夠處理到大概50,000連接，或者更多。(每個accepted socket大概消耗1.5kb，每個連接上post一個overlapped操作，分配一個IRP,大概需要500 byte, 總計：(1500+500)*50,000 = 100 Mb) 。
       無論是對于Locked Pages，還是對于non-paged pool使用，一旦超出了上限，Winsock調用僅僅會返回一般的WSAENOBUFS 或者ERROR_INSUFFICIENT_RESOURCES錯誤。為了處理這些錯誤，你可以試試以下的方法：
1） 需要首先調用SetWorkingSetSize,增加應用的可支配資源數，看能否解決。
2)     確信你的應用沒有做出太多的overlapped  IO操作。
3） 關閉一些連接數。
四) SOCKET的緩沖區設置問題。
         Winsock在默認的情況下，每個socket都會與一個send和receive buffer相關聯。你可以通過調用setsockopt來設置buffer的大小。
        在緩沖區沒有被關閉的情況下，我們看看overlapped send和revc是怎么工作的。
        當上層的應用做出了send調用，而這時如果send buffer還有剩余的空間，那么數據將會從用戶提交的buffer復制到send buffer中，然后調用返回成功。否則，假如這時send buffer已滿，用戶提交的buffer將會被鎖定，并且調用返回WSA_IO_PENDING。當send buffer的數據被下層的tcp處理完成，winsock將直接處理用戶提交的buffer里的數據，而不需要再復制。
        同樣，對于recv操作，如果數據已經被緩存在socket的receive buffer里，當發生recv調用的時候，數據將直接從socket的receive buffer復制到用戶的buffer里，recv調用返回成功。否則，假如發生調用時receive buffer里沒有數據，用戶提交的buffer將會被鎖定，recv調用返回WSA_IO_PENDING。當數據到達當前連接，將會被直接復制到用戶提交的buffer里。
        一個應用程序通過設定send buffer為0，把緩沖區關閉，然后發出一個阻塞send()調用。在這樣的情況下，系統內核會把應用程序的緩沖區鎖定，直到接收方確認收到了整個緩沖區后send()調用才返回。似乎這是一種判定你的數據是否已經為對方全部收到的簡潔的方法，實際上卻并非如此。想想看，即使遠端tcp通知數據已經收到，其實也根本不代表數據已經成功送給客戶端應用程序，比如對方可能發生資源不足的情況，導致afd.sys不能把數據拷貝給應用程序。另一個更要緊的問題是，在每個線程中每次只能進行一次發送調用，效率極其低下。
        另外，希望通過關閉Winsock緩沖區，從而避免數據復制，達到優化性能的目的，也是不可取的。從上面，我們看到：只要應用保證適量的，足夠的send, recv調用，這樣的復制是完全可以避免的。
        高性能的服務器應用程序可以關閉發送緩沖區，同時不會損失性能。不過，這樣的應用程序必須十分小心，保證它總是發出多個重疊發送調用，而不是等待某個重疊發送結束了才發出下一個。如果應用程序是按一個發完再發下一個的順序來操作，那浪費掉兩次發送中間的空檔時間，總之是要保證傳輸驅動程序在發送完一個緩沖區后，立刻可以轉向另一個緩沖區。
        如果關閉了recv buffer，在你的應用沒有保證足夠的recv操作前提下，任何進來數據，必須在TCP層進行緩存，最大緩存的數量將取決于tcp windows的大小(17Kb)。而最為嚴重的是這些緩存是從non-paged pool分配而來。如上所述，non-paged pool是非常珍貴，稀缺的內存。所以，從這個意義上來講，關閉了recv buffer操作是不可取的。
    這是2007年最后一篇帖子，最后祝大家新年快樂，過個好年！！！