• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 64, 文章 - 11, 評論 - 12, 引用 - 0
            數(shù)據(jù)加載中……

            2012-8 <中> 疑問

            20日
               用visual studio 10.0打開項目,第一次編譯項目,報出了“fatal error C1902: 程序數(shù)據(jù)庫管理器不匹配;請檢查安裝”的錯誤,但項目在上星期五都能編譯成功,
               現(xiàn)在沒有修改,卻編譯失敗。編譯其它語言的項目不受影響。
                  http://msdn.microsoft.com/zh-cn/library/8y7hea02.aspx是關(guān)于該問題的官方分析,于是我檢查相關(guān)的DLL文件,也都存在且版本一致。突然想起周五下午,
                  在使用vc10.0中的dumpbin時,提示少了mspdb100.dll文件,我就從Microsoft Visual Studio 10.0\Common7\IDE目錄中復制了該文件到
                  Microsoft Visual Studio 10.0\VC\bin中,把bin中的該文件刪除后,再編譯項目就成功了。

            23日
               程序每次隔幾分鐘去查詢服務(wù)器。響應(yīng)時間都會更長,特別是數(shù)據(jù)量少時更是慢。
                  通過wireshark工具分析網(wǎng)絡(luò)包,發(fā)現(xiàn)發(fā)生這個情況時總是發(fā)生了重傳并出現(xiàn)了ARP請求應(yīng)答包。于是試著清除ARP緩存,然后再查詢,情況一般都能復現(xiàn)。由此再
                  想到網(wǎng)絡(luò)協(xié)議ARP的介紹,得出結(jié)論是分片的IP包只有最后一包會由ARP應(yīng)答處理,之前的都會被丟棄。數(shù)據(jù)量少時更明顯的原因是沒有3個以上重復的ACK來告訴
                  需要重傳,只有等待超時機制,而超時機制一般都需要200多ms,所以現(xiàn)象更明顯。

               ARP 緩存表的更新。
                   在注冊表的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下有兩個鍵可用來控制緩存表的更新周期。
                  ArpCacheLife   REG_DWORD   0-0xFFFFFFFF(秒數(shù),默認值為120秒):是指沒有引用過(也就是和對方?jīng)]有通信)的緩存項失效時間。
                  ArpCacheMinReferencedLife   REG_DWORD   0-0xFFFFFFFF(秒數(shù),默認值為600):是指引用過(也就是和對方有網(wǎng)絡(luò)通信)的緩存項失效時間。

            24日
               程序在服務(wù)器上運行,點出關(guān)閉,遲遲不能退出。
                  用調(diào)試器附加進程,查看線程及各自的棧k,分析出有死循環(huán)。凍結(jié)其它線程~f,于循環(huán)判斷處下斷bp,查看相關(guān)存儲位置的值dd [ebp-38],更改其值ed [ebp-38]
                  查看寄存器eax的值reax,并重新賦值reax=1,從而讓程序完成退出時的邏輯。
             
            25日
               套接字模式分為兩種。
                  阻塞模式:在阻塞模式下,I/O操作完成前,執(zhí)行操作的調(diào)用send,recv會一直等候下去,不會立即返回到程序。
                  非阻塞模式:在非阻塞模式下,調(diào)用send,recv等I/O操作時,操作會立即返回到程序。
               windows上套接字上的I/O模型共有6種。
                  阻塞模型:模型使用阻塞模式的套接字,收發(fā)線程上進行的都是阻塞調(diào)用。特點是簡單,缺點是不易擴展。
                  select模型:可以同時管理阻塞套按字和非阻塞套接字。
                  WSAAsyncSelect模型:可以綁定到窗口的消息上,只能用非阻塞套接字上。
                  WSAEventSelect模型:和一個事件句柄關(guān)聯(lián),只能用非阻塞套接字上。
                  Overlapped I/O模型:可以和一個事件句柄或者一個完成回調(diào)方法關(guān)聯(lián),只能用非阻塞套接字上。
                  完成端口模型:只能用非阻塞套接字上。

               在一個阻塞或者非阻塞套接字上投遞recv操作時,默認的選項的行為是只要有數(shù)據(jù)就會返回。如果要讓套接字收到指定的數(shù)據(jù)量后才返回,需要在recv調(diào)用中指定MSG_WAITALL
               標志。
            30日
               MFC對話框上的ENTER,ESC及右上角的關(guān)閉按鈕處理
                  在MFC對話框上按ENTER鍵
                     1:如果當前焦點是在一個按鈕上,相當于單擊該按鈕。
                     2:如果當前焦點是在其它類型的控件上時。
                        2.1:如果設(shè)置了DEFAULT BUTTON按鈕,就相當于單擊了該默認按鈕。
                        2.3:如果映射了IDOK消息號,將會調(diào)用該消息函數(shù)
                        2.2:如果沒有設(shè)置DEFAULT BUTTON按鈕,將會調(diào)用對話框類的OnOK函數(shù)。
                  在MFC對話框上按下了ESC鍵
                     1:如果映射了IDCANCEL消息號,將會調(diào)用該消息函數(shù)。
                     2:如果沒有映射IDCANCEL消息號,將會調(diào)用對話框類的OnCancel函數(shù)。
                  單擊對話框右上角的關(guān)閉按鈕
                     1:如果映射了對話框WM_CLOSE消息,將調(diào)用該處理函數(shù)OnClose(),基類的OnClose()函數(shù)將會調(diào)用OnCancel函數(shù)。
                     2:同在MFC對話框上按下了ESC鍵處理流程一樣。
               參照上述的流程就可以靈活處理對話框上這幾個消息,也有人通過重載基類的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)處理好了,不需再進行處理。
                          }

                          return CDialog::PreTranslateMessage(pMsg);
                  }



                  

            posted on 2012-08-20 09:22 Robertxiao 閱讀(272) 評論(0)  編輯 收藏 引用 所屬分類: 問題集錦

            99久久婷婷免费国产综合精品| 中文字幕无码精品亚洲资源网久久| 九九久久自然熟的香蕉图片| 久久ZYZ资源站无码中文动漫| 久久九九青青国产精品| 欧洲性大片xxxxx久久久| 久久久精品国产sm调教网站 | 97久久超碰国产精品2021| 久久国产综合精品五月天| 无码久久精品国产亚洲Av影片| 国产免费久久久久久无码| 中文字幕人妻色偷偷久久| 欧美精品福利视频一区二区三区久久久精品 | 青青草原综合久久| 亚洲国产精品无码久久久不卡| 久久线看观看精品香蕉国产| 亚洲国产精品成人久久| 久久久这里有精品| 久久久久无码精品国产app| 青青草原综合久久| 久久91亚洲人成电影网站| 色偷偷88888欧美精品久久久| 亚洲国产成人久久笫一页| 久久成人永久免费播放| 久久综合丁香激情久久| 97久久精品无码一区二区| 久久中文骚妇内射| 综合网日日天干夜夜久久| 久久99精品久久久大学生| 思思久久好好热精品国产| 亚洲欧美久久久久9999| 日本亚洲色大成网站WWW久久 | 亚洲精品无码久久久久| 色诱久久av| 狠狠色综合网站久久久久久久高清| 亚洲国产精品综合久久网络 | 欧美亚洲国产精品久久久久| 亚洲国产日韩欧美综合久久| 久久久青草青青国产亚洲免观| 久久国产午夜精品一区二区三区| 中文字幕一区二区三区久久网站|