• <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)  編輯 收藏 引用 所屬分類: 問題集錦

            国产精品丝袜久久久久久不卡 | 亚洲日本va午夜中文字幕久久| 国产精品乱码久久久久久软件| 久久久精品国产sm调教网站 | 国产69精品久久久久APP下载| 2021国产精品午夜久久| 精品精品国产自在久久高清 | 国内精品伊人久久久久妇| 亚洲国产精品久久电影欧美| 99久久精品免费看国产| 久久久久国色AV免费观看| 久久精品国产精品国产精品污 | 波多野结衣中文字幕久久| 精品国产婷婷久久久| 久久99毛片免费观看不卡| 亚洲精品无码专区久久同性男| 国产午夜免费高清久久影院| 一本伊大人香蕉久久网手机| 色欲综合久久中文字幕网| 欧美综合天天夜夜久久| av色综合久久天堂av色综合在| 青青热久久综合网伊人| 色欲久久久天天天综合网精品| 久久婷婷五月综合97色直播| 国产精品久久一区二区三区| 一本色道久久88综合日韩精品| 99国产欧美久久久精品蜜芽| 伊人色综合久久天天人手人婷 | 伊人久久精品线影院| 久久精品国产亚洲av麻豆色欲| 国产精品激情综合久久| 久久91亚洲人成电影网站| 久久99亚洲综合精品首页| 久久综合噜噜激激的五月天| 精品国产综合区久久久久久| 精品永久久福利一区二区| 久久久久99精品成人片三人毛片| 亚洲国产精品成人久久| 亚洲人成电影网站久久| 999久久久国产精品| 91精品免费久久久久久久久|