緩衝區已被填滿或對方的接受緩衝區已被填滿。這種情況你實際上不用馬上理睬。因為CAsyncSocket會
記得你的Send WSAEWOULDBLOCK了，待傳送的資料會寫入CAsyncSocket內部的傳送緩衝區，並會在不忙的
時候自動呼叫OnSend，傳送內部緩衝區裡的資料。3、部分完成，0<Send(pBuf,nLen)<nLen，導致這種情況的原因是，你的傳送緩衝區或對方的接收緩衝區
中剩餘的空位不足以容納你這次需要傳送的全部資料。處理這種情況的通常做法是繼續傳送尚未傳送的
資料直到全部完成或WSAEWOULDBLOCK。這種情況很容易讓人產生疑惑，既然緩衝區空位不足，那麼本次
傳送就已經填滿了緩衝區，幹嘛還要繼續傳送呢，就像WSAEWOULDBLOCK了一樣直接交給OnSend去處理剩
餘資料的傳送不是更合理嗎？然而很遺憾，CAsyncSocket不會記得你只完成了部分傳送任務從而在合適
的時候觸發OnSend，因為你並沒有WSAEWOULDBLOCK。你可能認為既然已經填滿緩衝區，繼續傳送必然會
WSAEWOULDBLOCK，其實不然，假如WSAEWOULDBLOCK是由於對方讀取接收緩衝區不及時引起的，繼續傳送
的確很可能會WSAEWOULDBLOCK，但假如WSAEWOULDBLOCK是由於傳送緩衝區被填滿，就不一定了，因為你
的網路卡處理髮送緩衝區中資料的速度不見得比你往傳送緩衝區拷貝資料的速度更慢，這要取決與你競爭
CPU、記憶體、頻寬資源的其他應用程式的具體情況。假如這時候CPU負載較大而網路卡負載較低，則雖然剛
剛傳送緩衝區是滿的，你繼續傳送也不會WSAEWOULDBLOCK。4、完成，Send(pBuf,nLen)==nLen與OnSend協助Send完成工作一樣，OnRecieve、OnConnect、OnAccept也會分別協助Recieve、Connect、
Accept完成工作。這一切都通過訊息機制完成：在你使用CAsyncSocket之前，必須呼叫AfxSocketInit初始化WinSock環境，而AfxSocketInit會建立一個
隱藏的CSocketWnd物件，由於這個物件由Cwnd派生，因此它能夠接收Windows訊息。所以它能夠成為高層
CAsyncSocket物件與WinSock底層之間的橋樑。例如某CAsyncSocket在Send時WSAEWOULDBLOCK了，它就會
傳送一條訊息給CSocketWnd作為報告，CSocketWnd會維護一個報告登記表，當它收到底層WinSock發出的
空閒訊息時，就會檢索報告登記表，然後直接呼叫報告者的OnSend函式。所以前文所說的CAsyncSocket會
自動呼叫OnXxx，實際上是不對的，真正的呼叫者是CSocketWnd——它是一個CWnd物件，執行在獨立的線
程中。使用CAsyncSocket時，Send流程和Recieve流程是不同的，不理解這一點就不可能順利使用CAsyncSocket。MSDN對CAsyncSocket的解釋很容易讓你理解為：只有OnSend被觸發時你Send才有意義，你才應該Send，
同樣只有OnRecieve被觸發時你才應該Recieve。很不幸，你錯了：你會發現，連線建立的同時，OnSend就第一次被觸發了，嗯，這很好，但你現在還不想Send，你讓OnSend
返回，乾點其他的事情，等待下一次OnSend試試看？實際上，你再也等不到OnSend被觸發了。因為，除
了第一次以外，OnSend的任何一次觸發，都源於你呼叫了Send，但碰到了WSAEWOULDBLOCK！所以，使用CAsyncSocket時，針對傳送的流程邏輯應該是：你需兩個成員變數，一個傳送任務表，一個
記錄傳送進度。你可以，也應該，在任何你需要的時候，主動呼叫Send來傳送資料，同時更新任務表和
傳送進度。而OnSend，則是你的負責擦屁股工作的助手，它被觸發時要乾的事情就是根據任務表和傳送
進度呼叫Send繼續發。若又沒能將任務表全部傳送完成，更新傳送進度，退出，等待下一次OnSend；若
任務表已全部傳送完畢，則清空任務表及傳送進度。使用CAsyncSocket的接收流程邏輯是不同的：你永遠不需要主動呼叫Recieve，你只應該在OnRecieve中等
待。由於你不可能知道將要抵達的資料型別及次序，所以你需要定義一個已收資料表作為成員變數來儲存

已收到但尚未處理的資料。每次OnRecieve被觸發，你只需要被動呼叫一次Recieve來接受固定長度的資料，
並新增到你的已收資料表後。然後你需要掃描已收資料表，若其中已包含一條或數條完整的可解析的業務
資料包，擷取出來，呼叫業務處理視窗的處理函式來處理或作為訊息引數傳送給業務處理視窗。而已收數
據表中剩下的資料，將等待下次OnRecieve中被再次組合、掃描並處理。在長連線應用中，連線可能因為各種原因中斷，所以你需要自動重連。你需要根據CAsyncSocket的成員變
量m_hSocket來判斷當前連線狀態：if(m_hSocket==INVALID_SOCKET)。當然，很奇怪的是，即使連線已經
中斷，OnClose也已經被觸發，你還是需要在OnClose中主動呼叫Close，否則m_hSocket並不會被自動賦值
為INVALID_SOCKET。在很多長連線應用中，除建立連線以外，還需要先Login，然後才能進行業務處理，連線並Login是一個步
驟依賴性過程，用非同步方式處理反而會很麻煩，而CAsyncSocket是支援切換為同步模式的，你應該掌握在
適當的時候切換同非同步模式的方法：DWORD dw;//切換為同步模式
dw=0;
IOCtl(FIONBIO,&dw);
...//切換回非同步模式
dw=1;
IOCtl(FIONBIO,&dw);
三、CSocket的用法CSocket在CAsyncSocket的基礎上，修改了Send、Recieve等成員函式，幫你內建了一個用以輪詢收發緩衝區
的迴圈，變成了同步短連線模式。短連線應用簡單明瞭，CSocket經常不用派生就可以直接使用，但也有些問題：1、用作監聽的時候曾經看到有人自己建立執行緒，線上程中建立CSocket物件進行Listen、Accept，若Accept成功則再起一個線
程繼續Listen、Accept。。。可以說他完全不理解CSocket，實際上CSocket的監聽機制已經內建了多執行緒機
制，你只需要從CSocket派生，然後過載OnAccept：//CListenSocket標頭檔案
class CListenSocket : public CSocket
{
public:
CListenSocket(HWND hWnd=NULL);
HWND m_hWnd; //事件處理視窗
virtual void OnAccept(int nErrorCode);
};//CListenSocket實現檔案
#include "ListenSocket.h"
CListenSocket::CListenSocket(HWND hWnd){m_hWnd=hWnd;}
void CListenSocket::OnAccept(int nErrorCode)
{
SendMessage(m_hWnd,WM_SOCKET_MSG,SOCKET_CLNT_ACCEPT,0);
CSocket::OnAccept(nErrorCode);
}//主執行緒
...
m_pListenSocket=new CListenSocket(m_hWnd);
m_pListenSocket->Create(...);
m_pListenSocket->Listen();
...LRESULT CXxxDlg::OnSocketMsg(WPARAM wParam, LPARAM lParam)
{
UINT type=(UINT)wParam;
switch(type)
{
case SOCKET_CLNT_ACCEPT:
{
CSocket* pSocket=new CSocket;
if(!m_pListenSocket->Accept(*pSocket))
{
delete pSocket;
break;
}
...
}
...
}
}
2、用於多執行緒的時候常看到人說CSocket在子執行緒中不能用，其實不然。實際情況是：直接使用CSocket動態建立的物件，將其指標作為引數傳遞給子執行緒，則子執行緒中進行收發等各種操作都
沒問題。但如果是使用CSocket派生類建立的物件，就要看你過載了哪些方法，假如你僅過載了OnClose，
則子執行緒中你也可以正常收發，但不能Close!因為CSocket是用內部迴圈做到同步的，並不依賴各OnXxx，它不需要與CSocketWnd互動。但當你派生並重
載OnXxx後，它為了提供訊息機制就必須與CSocketWnd互動。當你呼叫AfxSocketInit時，你的主執行緒會獲
得一個訪問CSocketWnd的控制程式碼，對CSocketWnd的訪問是MFC自動幫你完成的，是被隱藏的。而你自己建立
的子執行緒並不自動具備訪問CSocketWnd的機制，所以子執行緒中需要訪問CSocketWnd的操作都會失敗。常看到的解決辦法是給子執行緒傳遞SOCKET控制程式碼而不是CSocket物件指標，然後在子執行緒中建立CSocket臨時
物件並Attach傳入的控制程式碼，用完後再Dettach並delete臨時物件。俺沒有這麼幹過，估計是因為Attach方法
含有獲取CSocketWnd控制程式碼的內建功能。俺的解決方案還是使用自定義訊息，比如俺不能在子執行緒中Close，那麼，俺可以給主執行緒傳送一條訊息，
讓主執行緒的訊息處理函式來完成Close，也很方便。CSocket一般配合多執行緒使用，只要你想收發資料，你就可以建立一個CSocket物件，並建立一個子執行緒來
進行收發。所以被阻塞的只是子執行緒，而主執行緒總是可以隨時建立子執行緒去幫它幹活。由於可能同時有很
多個CSocket物件在工作，所以你一般還要建立一個列表來儲存這些CSocket物件的標識，這樣你可能通過
在列表中檢索標識來區分各個CSocket物件，當然，由於記憶體地址的唯一性，物件指標本身就可以作為標識。
相對CAsyncSocket而言，CSocket的運作流程更直觀也更簡單，至於CSocketFile、CArchive之類的，似乎
也不需要多說什麼，就這樣結束吧。 

轉自：創意安天論壇

好多字...