20日
用visual studio 10.0打開項(xiàng)目，第一次編譯項(xiàng)目，報(bào)出了“
fatal error C1902: 程序數(shù)據(jù)庫(kù)管理器不匹配；請(qǐng)檢查安裝”的錯(cuò)誤，但項(xiàng)目在上星期五都能編譯成功，
現(xiàn)在沒有修改，卻編譯失敗。編譯其它語言的項(xiàng)目不受影響。
http://msdn.microsoft.com/zh-cn/library/8y7hea02.aspx是關(guān)于該問題的官方分析，于是我檢查相關(guān)的DLL文件，也都存在且版本一致。突然想起周五下午，
在使用vc10.0中的dumpbin時(shí)，提示少了mspdb100.dll文件，我就從Microsoft Visual Studio 10.0\Common7\IDE目錄中復(fù)制了該文件到
Microsoft Visual Studio 10.0\VC\bin中，把bin中的該文件刪除后，再編譯項(xiàng)目就成功了。
23日
程序每次隔幾分鐘去查詢服務(wù)器。響應(yīng)時(shí)間都會(huì)更長(zhǎng)，特別是數(shù)據(jù)量少時(shí)更是慢。
通過wireshark工具分析網(wǎng)絡(luò)包，發(fā)現(xiàn)發(fā)生這個(gè)情況時(shí)總是發(fā)生了重傳并出現(xiàn)了ARP請(qǐng)求應(yīng)答包。于是試著清除ARP緩存，然后再查詢，情況一般都能復(fù)現(xiàn)。由此再
想到網(wǎng)絡(luò)協(xié)議ARP的介紹，得出結(jié)論是分片的IP包只有最后一包會(huì)由ARP應(yīng)答處理，之前的都會(huì)被丟棄。數(shù)據(jù)量少時(shí)更明顯的原因是沒有3個(gè)以上重復(fù)的ACK來告訴
需要重傳，只有等待超時(shí)機(jī)制，而超時(shí)機(jī)制一般都需要200多ms，所以現(xiàn)象更明顯。
ARP 緩存表的更新。
在注冊(cè)表的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下有兩個(gè)鍵可用來控制緩存表的更新周期。
ArpCacheLife REG_DWORD 0-0xFFFFFFFF(秒數(shù),默認(rèn)值為120秒)：是指沒有引用過（也就是和對(duì)方?jīng)]有通信）的緩存項(xiàng)失效時(shí)間。
ArpCacheMinReferencedLife REG_DWORD 0-0xFFFFFFFF(秒數(shù),默認(rèn)值為600)：是指引用過（也就是和對(duì)方有網(wǎng)絡(luò)通信)的緩存項(xiàng)失效時(shí)間。
24日
程序在服務(wù)器上運(yùn)行，點(diǎn)出關(guān)閉，遲遲不能退出。
用調(diào)試器附加進(jìn)程，查看線程及各自的棧k，分析出有死循環(huán)。凍結(jié)其它線程~f，于循環(huán)判斷處下斷bp，查看相關(guān)存儲(chǔ)位置的值dd [ebp-38]，更改其值ed [ebp-38]
查看寄存器eax的值reax，并重新賦值reax=1，從而讓程序完成退出時(shí)的邏輯。
25日
套接字模式分為兩種。
阻塞模式：在阻塞模式下，I/O操作完成前，執(zhí)行操作的調(diào)用send，recv會(huì)一直等候下去，不會(huì)立即返回到程序。
非阻塞模式：在非阻塞模式下，調(diào)用send，recv等I/O操作時(shí)，操作會(huì)立即返回到程序。
windows上套接字上的I/O模型共有6種。
阻塞模型：模型使用阻塞模式的套接字，收發(fā)線程上進(jìn)行的都是阻塞調(diào)用。特點(diǎn)是簡(jiǎn)單，缺點(diǎn)是不易擴(kuò)展。
select模型：可以同時(shí)管理阻塞套按字和非阻塞套接字。
WSAAsyncSelect模型：可以綁定到窗口的消息上，只能用非阻塞套接字上。
WSAEventSelect模型：和一個(gè)事件句柄關(guān)聯(lián)，只能用非阻塞套接字上。
Overlapped I/O模型：可以和一個(gè)事件句柄或者一個(gè)完成回調(diào)方法關(guān)聯(lián)，只能用非阻塞套接字上。
完成端口模型：只能用非阻塞套接字上。
在一個(gè)阻塞或者非阻塞套接字上投遞recv操作時(shí)，默認(rèn)的選項(xiàng)的行為是只要有數(shù)據(jù)就會(huì)返回。如果要讓套接字收到指定的數(shù)據(jù)量后才返回，需要在recv調(diào)用中指定MSG_WAITALL
標(biāo)志。
30日
MFC對(duì)話框上的ENTER，ESC及右上角的關(guān)閉按鈕處理
在MFC對(duì)話框上按ENTER鍵
1：如果當(dāng)前焦點(diǎn)是在一個(gè)按鈕上，相當(dāng)于單擊該按鈕。
2：如果當(dāng)前焦點(diǎn)是在其它類型的控件上時(shí)。
2.1：如果設(shè)置了DEFAULT BUTTON按鈕，就相當(dāng)于單擊了該默認(rèn)按鈕。
2.3：如果映射了IDOK消息號(hào)，將會(huì)調(diào)用該消息函數(shù)
2.2：如果沒有設(shè)置DEFAULT BUTTON按鈕，將會(huì)調(diào)用對(duì)話框類的OnOK函數(shù)。
在MFC對(duì)話框上按下了ESC鍵
1：如果映射了IDCANCEL消息號(hào)，將會(huì)調(diào)用該消息函數(shù)。
2：如果沒有映射IDCANCEL消息號(hào)，將會(huì)調(diào)用對(duì)話框類的OnCancel函數(shù)。
單擊對(duì)話框右上角的關(guān)閉按鈕
1：如果映射了對(duì)話框WM_CLOSE消息，將調(diào)用該處理函數(shù)OnClose()，基類的OnClose()函數(shù)將會(huì)調(diào)用OnCancel函數(shù)。
2：同在MFC對(duì)話框上按下了ESC鍵處理流程一樣。
參照上述的流程就可以靈活處理對(duì)話框上這幾個(gè)消息，也有人通過重載基類的BOOL PreTranslateMessage(MSG* pMsg) 來處理
BOOL PreTranslateMessage(MSG* pMsg)
{
// TODO: Add your specialized code here and/or call the base class
if (pMsg-> message==WM_KEYDOWN)
{
UINT nkeyc=(UINT)(pMsg-> wParam);
if(nkeyc==VK_ESCAPE)
return TRUE; // 表示已經(jīng)處理好了，不需再進(jìn)行處理。
}
return CDialog::PreTranslateMessage(pMsg);
}