• <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>
            面對現實,超越自己
            逆水行舟,不進則退
            posts - 269,comments - 32,trackbacks - 0
            來源:
            http://portableapps.com/node/12561
            下載
            http://zer0dev.com/dld/download.php?id=27

            頭文件使用:
            1. !include "ProcFunc.nsh"
            2. 可使用范圍:$var為返回值
            [Section|Function]
            ${ProcFunction} "參數1" "參數2" "..." $var
            [SectionEnd|FunctionEnd]

            ${ProcessExists} "[process]"
                "[process]"            ; Name or PID

                Use with a LogicLib conditional command like If or Unless.
                Evaluates to true if the process exists or false if it does not or
                the CreateToolhelp32Snapshot fails.

            ${GetProcessPID} "[process]" $var
                "[process]"            ; Name or PID
               
                $var(output)          ; -2 - CreateToolhelp32Snapshot failed
                                           ;  0 - process does not exist
                                           ; >0 - PID

            ${GetProcessPath} "[process]" $var
                "[process]"            ; Name or PID
               
                $var(output)          ; -2 - CreateToolhelp32Snapshot failed
                                           ; -1 - OpenProcess failed
                                           ;  0 - process does not exist
                                           ; Or path to process

            ${GetProcessParent} "[process]" $var
                "[process]"            ; Name or PID

                $var(output)          ; -2 - CreateToolhelp32Snapshot failed
                                           ;  0 - process does not exist
                                           ; Or PPID

            ${GetProcessName} "[PID]" $var
                "[PID]"                 ; PID

                $var(output)         ; -2 - CreateToolhelp32Snapshot failed
                                          ;  0 - process does not exist
                                          ; Or process name

            ${EnumProcessPaths} "Function" $var
                "Function"            ; Callback function
                $var(output)         ; -2 - EnumProcesses failed
                                          ;  1 - success

                Function "Function"
                    Pop $var1        ; matching path string
                    Pop $var2        ; matching process PID
                    ...user commands
                    Push [1/0]       ; must return 1 on the stack to continue
                                         ; must return some value or corrupt the stack
                                         ; DO NOT save data in $0-$9
                FunctionEnd

            ${ProcessWait} "[process]" "[timeout]" $var
                "[process]"          ; Name
                "[timeout]"          ; -1 - do not timeout
                                         ; >0 - timeout in milliseconds

                $var(output)        ; -2 - CreateToolhelp32Snapshot failed
                                         ; -1 - operation timed out
                                         ; Or PID

            ${ProcessWait2} "[process]" "[timeout]" $var
                "[process]"          ; Name
                "[timeout]"          ; -1 - do not timeout
                                         ; >0 - timeout in milliseconds

                $var(output)        ; -1 - operation timed out
                                         ; Or PID

            ${ProcessWaitClose} "[process]" "[timeout]" $var
                "[process]"          ; Name
                "[timeout]"          ; -1 - do not timeout
                                         ; >0 - timeout in milliseconds

                $var(output)        ; -1 - operation timed out
                                         ;  0 - process does not exist
                                         ; Or PID of ended process

            ${CloseProcess} "[process]" $var
                "[process]"          ; Name or PID

                $var(output)        ; 0 - process does not exist
                                         ; Or PID of ended process

            ${TerminateProcess} "[process]" $var
                "[process]"          ; Name or PID

                $var(output)        ; -1 - operation failed
                                         ;  0 - process does not exist
                                         ; Or PID of ended process

            ${Execute} "[command]" "[working_dir]" $var
                "[command]"        ; '"X:\path\to\prog.exe" arg1 arg2 "arg3 with space"'
                "[working_dir]"     ; Working directory ("X:\path\to\dir") or nothing ("")

                $var(output)        ; 0 - failed to create process
                                         ; Or PID
            */

            本文轉自:http://www.dreams8.com/forum.php?mod=viewthread&tid=17067&fromuid=1
            posted @ 2012-10-18 14:09 王海光 閱讀(862) | 評論 (0)編輯 收藏
            以下為示例腳本:
            1 !define MyMutex_Update     "MyMutex_Update"
            2 
            3 
            4 Section
            5     System::Call 'kernel32::CreateMutexA(i 0, i 0, t "${MyMutex_Update}") i .r1 ?e'
            6     Pop $R0
            7     StrCmp $R0 0 +2
            8     Quit
            9 SectionEnd


            其他文章:http://blog.csdn.net/shemny/article/details/7575038
            posted @ 2012-10-18 14:02 王海光 閱讀(666) | 評論 (0)編輯 收藏
             1     CString sTempIPs;
             2     sTempIPs.Format("%s%s", CCommonFun::GetTmpPath(), "TempIPs.txt");
             3 
             4     ::DeleteFile(sTempIPs);
             5     CString sPara;
             6     sPara.Format("/c ipconfig.exe | findstr \"IP Address\" > \"%s\"", sTempIPs);
             7     CCommonFun::WinExecAndWait32("cmd.exe", sPara, CCommonFun::GetExecutablePath(), INFINITE);
             8 
             9     if (CFileFind().FindFile(sTempIPs))
            10     {
            11         CString sLine, sIP;
            12         CString sFlag = "";
            13         CStdioFile stdFile;
            14         if (stdFile.Open(sTempIPs,  CFile::modeRead))
            15         {
            16             while (stdFile.ReadString(sLine))
            17             {
            18                 int nPos = sLine.Find(sFlag);
            19                 if (nPos != -1)
            20                 {
            21                     sIP = sLine.Mid(nPos+sFlag.GetLength(), sLine.GetLength()-(nPos+sFlag.GetLength()));
            22                     sIP.TrimLeft();
            23                     sIP.TrimRight();
            24                     arsLocalIPs.Add(sIP);
            25                 }
            26             }
            27         }
            28     }
            posted @ 2012-09-29 14:33 王海光 閱讀(562) | 評論 (0)編輯 收藏
                 摘要:       在開機啟動應用程序時,可能會碰到權限不夠而啟動失敗或者一些其他問題,所以在開機啟動程序時可能會使用SYSTEM權限,但由于后來的操作不需要高權限來完成,就需要降低應用程序的權限。可以通過獲取explorer.exe進程ID來實現。 Code highlighting produced by Actipro CodeHigh...  閱讀全文
            posted @ 2012-09-29 14:22 王海光 閱讀(1213) | 評論 (0)編輯 收藏
             半個月前在豆瓣上看到了一本新書《數學之美》,評價很高。而因為在半年前看了《什么是數學》就對數學產生濃厚興趣,但苦于水平不足的我便立馬買了一本,希望能對數學多一些了解,并認真閱讀起來。
                    令我意外并欣喜的是,這本書里邊的數學內容并不晦澀難懂,而且作者為了講述數學之美而搭配的一些工程實例都是和我學習并感興趣的模式識別,目標分類相關算法相關聯的。這讓我覺得撿到了意外的寶藏。
                    書中每一個章節都或多或少是作者親身經歷過的,比如世界級教授的小故事,或者Google的搜索引擎原理,又或者是Google的云計算等。作者用其行云流水般的語言將各個知識點像講故事一樣有趣的敘述出來。
                    這本書著實讓我印象深刻,所以我把筆記分享出來,希望更多和我學習研究領域一樣的人會喜歡并親自閱讀這本書,并能支持作者。畢竟國內這種書實在是太少了,也希望能有更多領域內的大牛能再寫出一些這種書籍來讓我們共同提高。
            1.    因為需要傳播信息量的增加,不同的聲音并不能完全表達信息,語言便產生了。
            2.    當文字增加到沒有人能完全記住所有文字時,聚類和歸類就開始了。例如日代表太陽或者代表一天。
            3.    聚類會帶來歧義性,但上下文可以消除歧義。信息冗余是信息安全的保障。例如羅塞塔石碑上同一信息重復三次。
            4.    最短編碼原理即常用信息短編碼,生僻信息長編碼。
            5.    因為文字只是信息的載體而非信息本身,所以翻譯是可以實現的。
            6.    2012,其實是瑪雅文明采用二十進制,即四百年是一個太陽紀,而2012年恰巧是當前太陽紀的最后一年,2013年是新的太陽紀的開始,故被誤傳為世界末日。
            7.    字母可以看為是一維編碼,而漢字可以看為二維編碼。
            8.    基于統計的自然語言處理方法,在數學模型上和通信是相通的,甚至是相同的。
            9.    讓計算機處理自然語言的基本問題就是為自然語言這種上下文相關的特性建立數學模型,即統計語言模型(Statistical Language Modal)。
            10.    根據大數定理(Law of Large Numbers),只要統計量足夠,相對頻度就等于概率。
            11.    二元模型。對于p(w1,w2,…,wn)=p(w1)p(w2|w1)p(w3|w1,w2)…p(wn|w1,w2,…,wn-1)的展開問題,因為p(w3|w1,w2)難計算,p(wn|w1,w2,…,wn-1)更難計算,馬爾科夫給出了一個偷懶但是頗為有效的方法,也就是每當遇到這種情況時,就假設任意wi出現的概率只與它前面的wi-1有關,即p(s)=p(w1)p(w2|w1)p(w3|w2)…p(wi|wi-1)…p(wn|wn-1)。現在這個概率就變的簡單了。對應的語言模型為2元模型(Bigram Model)。
            12.    *N元模型。wi只與前一個wi-1有關近似的過頭了,所以N-1階馬爾科夫假設為p(wi|w1,w2,…,wi-1)=p(wi|wi-N+1,wi-N+2,…,wi-1),對應的語言模型成為N元模型(N-Gram Model)。一元模型就是上下文無關模型,實際應用中更多實用的是三元模型。Google的羅塞塔翻譯系統和語言搜索系統實用的是四元模型,存儲于500臺以上的Google服務器中。
            13.    *卡茲退避法(Katz backoff),對于頻率超過一定閾值的詞,它們的概率估計就是它們在語料庫中的相對頻度,對于頻率小于這個閾值的詞,它們的概率估計就小于他們的相對頻度,出現次數越少,頻率下調越多。對于未看見的詞,也給予一個比較小的概率(即下調得到的頻率總和),這樣所有詞的概率估計都平滑了。這就是卡茲退避法(Katz backoff)。
            14.    訓練數據通常是越多越好,通過平滑過渡的方法可以解決零概率和很小概率的問題,畢竟在數據量多的時候概率模型的參數可以估計的比較準確。
            15.    利用統計語言模型進行分詞,即最好的分詞方法應該保證分完詞后這個句子出現的概率最大。根據不同應用,漢語分詞的顆粒度大小應該不同。
            16.    符合馬爾科夫假設(各個狀態st的概率分布只與它前一個狀態st-1有關)的隨即過程即成為馬爾科夫過程,也稱為馬爾科夫鏈。
            17.    隱含馬爾科夫模型是馬爾科夫鏈的擴展,任意時刻t的狀態st是不可見的,所以觀察者沒法通過觀察到一個狀態序列s1,s2,s3,…,sT來推測轉移概率等參數。但是隱馬爾科夫模型在每個時刻t會輸出一個符號ot,而且ot和st相關且僅和ot相關。這個被稱為獨立輸出假設。其中隱含的狀態s1,s2,s3,…是一個典型的馬爾科夫鏈。
            18.    隱含馬爾科夫模型是機器學習主要工具之一,和幾乎所有機器學習的模型工具一樣,它需要一個訓練算法(鮑姆-韋爾奇算法)和使用時的解碼算法(維特比算法)。掌握了這兩類算法,就基本上可以使用隱含馬爾科夫模型這個工具了。
            19.    鮑姆-韋爾奇算法(Baum-Welch Algorithm),首先找到一組能夠產生輸出序列O的模型參數,這個初始模型成為Mtheta0,需要在此基礎上找到一個更好的模型,假定不但可以算出這個模型產生O的概率P(O|Mtheta0),而且能夠找到這個模型產生O的所有可能的路徑以及這些路徑的概率。并算出一組新的模型參數theta1,從Mtheta0到Mtheta1的過程稱為一次迭代。接下來從Mtheta1出發尋找更好的模型Mtheta2,并一直找下去,直到模型的質量沒有明顯提高為止。這樣一直估計(Expectation)新的模型參數,使得輸出的概率達到最大化(Maximization)的過程被稱為期望值最大化(Expectation-Maximization)簡稱EM過程。EM過程能保證一定能收斂到一個局部最優點,但不能保證找到全局最優點。因此,在一些自然語言處理的應用中,這種無監督的鮑姆-韋爾奇算法訓練處的模型比有監督的訓練得到的模型效果略差。
            20.    熵,信息熵的定義為H(X)=-SumP(x)logP(x),變量的不確定性越大,熵也越大。
            21.    一個事物內部會存在隨機性,也就是不確定性,假定為U,而從外部消除這個不確定性唯一的辦法是引入信息I,而需要引入的信息量取決于這個不確定性的大小,即I>U才行。當I<U時,這些信息可以消除一部分不確定性,U'=U-I。反之,如果沒有信息,任何公示或者數字的游戲都無法排除不確定性。
            22.    信息的作用在于消除不確定性。
            23.    互信息,對兩個隨機事件相關性的量化度量,即隨機事件X的不確定性或者說熵H(X),在知道隨機事件Y條件下的不確定性,或者說條件熵H(X|Y)之間的差異,即I(X;Y)=H(X)-H(X|Y)。所謂兩個事件相關性的量化度量,即在了解了其中一個Y的前提下,對消除另一個X不確定性所提供的信息量。
            24.    相對熵(Kullback-Leibler Divergence)也叫交叉熵,對兩個完全相同的函數,他們的相對熵為零;相對熵越大,兩個函數差異越大,反之,相對熵越小,兩個函數差異越小;對于概率分布或者概率密度函數,如果取值均大于零,相對熵可以度量兩個隨機分布的差異性。
            25.    弗里德里克·賈里尼克(Frederek Jelinek)是自然語言處理真諦的先驅者。
            26.    技術分為術和道兩種,具體的做事方法是術,做事的原理和原則是道。術會從獨門絕技到普及再到落伍,追求術的人會很辛苦,只有掌握了道的本質和精髓才能永遠游刃有余。
            27.    真理在形式上從來是簡單的,而不是復雜和含混的。
            28.    搜索引擎不過是一張大表,表的每一行對應一個關鍵字,而每一個關鍵字后面跟著一組數字,是包含該關鍵詞的文獻序號。但當索引變的非常大的時候,這些索引需要通過分布式的方式存儲到不同的服務器上。
            29.    網絡爬蟲(Web Crawlers),圖論的遍歷算法和搜索引擎的關系。互聯網雖然復雜,但是說穿了其實就是一張大圖……可以把每一個網頁當做一個節點,把那些超鏈接當做連接網頁的弧。有了超鏈接,可以從任何一個網頁出發,用圖的遍歷算法,自動訪問到每一個網頁并且把他們存儲起來。完成這個功能的程序叫網絡爬蟲。
            30.    哥尼斯堡七橋,如果一個圖能從一個頂點出發,每條邊不重復的遍歷一遍回到這個頂點,那么每一個頂點的度必須為偶數。
            31.    構建網絡爬蟲的工程要點:1.用BFS(廣度優先搜索)還是DFS(深度優先搜索),一般是先下載完一個網站,再進入下一個網站,即BFS的成分多一些。2.頁面的分析和URL的提取,如果有些網頁明明存在,但搜索引擎并沒有收錄,可能的原因之一是網絡爬蟲中的解析程序沒能成功解析網頁中不規范的腳本程序。3.記錄哪些網頁已經下載過的URL表,可以用哈希表。最終,好的方法一般都采用了這樣兩個技術:首先明確每臺下載服務器的分工,也就是在調度時,一看到某個URL就知道要交給哪臺服務器去下載,這樣就避免了很多服務器對同一個URL做出是否需要下載的判斷。然后,在明確分工的基礎上,判斷URL是否下載就可以批處理了,比如每次向哈希表(一組獨立的服務器)發送一大批詢問,或者每次更新一大批哈希表的內容,這樣通信的次數就大大減少了。
            32.    PageRank衡量網頁質量的核心思想,在互聯網上,如果一個網頁被很多其他網頁所鏈接,說明它受到普遍的承認和信賴,那么它的排名就高。同時,對于來自不同網頁的鏈接區別對待,因為網頁排名高的那些網頁的鏈接更可靠,于是要給這些鏈接比較大的權重。
            33.    TF-IDF(Term Frequency / Inverse Document Frequency) ,關鍵詞頻率-逆文本頻率值,其中,TF為某個網頁上出現關鍵詞的頻率,IDF為假定一個關鍵詞w在Dw個網頁中出現過,那么Dw越大,w的權重越小,反之亦然,公式為log(D/Dw)。1.一個詞預測主題的能力越強,權重越大,反之,權重越小。2.停止詞的權重為零。
            34.    動態規劃(Dynamic Programming)的原理,將一個尋找全程最優的問題分解成一個個尋找局部最優的小問題。
            35.    一個好的算法應該像輕武器中最有名的AK-47沖鋒槍那樣:簡單、有效、可靠性好而且容易讀懂(易操作)而不應該故弄玄虛。選擇簡單方案可以容易解釋每個步驟和方法背后的道理,這樣不僅便于出問題時的查錯,也容易找到今后改進的目標。
            36.    在實際的分類中,可以先進行奇異值分解(得到分類結果略顯粗糙但能較快得到結果),在粗分類結果的基礎上,利用計算向量余弦的方法(對范圍內的分類做兩兩計算),在粗分類結果的基礎上,進行幾次迭代,得到比較精確的結果。
            37.    奇異值分解(Singular Value Decomposition),在需要用一個大矩陣A來描述成千上萬文章和幾十上百萬詞的關聯性時,計算量非常大,可以將A奇異值分解為X、B和Y三個矩陣,Amn=Xmm*Bmn*Ynn,X表示詞和詞類的相關性,Y表示文本和主題的相關性,B表示詞類和主題的相關性,其中B對角線上的元素很多值相對其他的非常小,或者為零,可以省略。對關聯矩陣A進行一次奇異值分解,就可以同時完成近義詞分類和文章的分類,同時能得到每個主題和每個詞義類之間的相關性,這個結果非常漂亮。
            38.    信息指紋。如果能夠找到一種函數,將5000億網址隨即地映射到128位二進制,也就是16字節的整數空間,就稱這16字節的隨機數做該網址的信息指紋。信息指紋可以理解為將一段信息映射到一個多維二進制空間中的一個點,只要這個隨即函數做的好,那么不同信息對應的點不會重合,因此這個二進制的數字就變成了原來信息所具有的獨一無二的指紋。
            39.    判斷兩個集合是否相同,最笨的方法是這個集合中的元素一一比較,復雜度O(squareN),稍好的是將元素排序后順序比較,復雜度O(NlogN),最完美的方法是計算這兩個集合的指紋,然后直接進行比較,計算復雜度O(N)。
            40.    偽隨機數產生器算法(Pseudo-Random Number Generator,PRNG),這是產生信息指紋的關鍵算法,通過他可以將任意長的整數轉換成特定長度的偽隨機數。最早的PRNG是將一個數的平方掐頭去尾取中間,當然這種方法不是很隨即,現在常用的是梅森旋轉算法(Mersenne Twister)。
            41.    在互聯網上加密要使用基于加密的偽隨機數產生器(Cryptography Secure Pseudo-Random Number Generator,CSPRNG),常用的算法有MD5或者SHA-1等標準,可以將不定長的信息變成定長的128位或者160位二進制隨機數。
            42.    最大熵模型(Maximum Entropy)的原理就是保留全部的不確定性,將風險降到最小。最大熵原理指出,需要對一個隨機事件的概率分布進行預測時,我們的預測應當滿足全部已知的條件,而對未知的情況不要做任何主觀假設。在這種情況下,概率分布最均勻,預測的風險最小。I.Csiszar證明,對任何一組不自相矛盾的信息,這個最大熵模型不僅存在,而且是唯一的,此外,他們都有同一個非常簡單的形式-指數函數。
            43.    通用迭代算法(Generalized Iterative Scaling,GIS)是最原始的最大熵模型的訓練方法。1.假定第零次迭代的初始模型為等概率的均勻分布。2.用第N次迭代的模型來估算每種信息特征在訓練數據中的分布。如果超過了實際的,就把相應的模型參數變小,反之變大。3.重復步驟2直至收斂。這是一種典型的期望值最大化(Expectation Maximization,EM)算法。IIS(Improved Iterative Scaling)比GIS縮短了一到兩個數量級。
            44.    布隆過濾器實際上是一個很長的二進制向量和一系列隨機映射的函數。
            45.    貝葉斯網絡從數學的層面講是一個加權的有向圖,是馬爾科夫鏈的擴展,而從知識論的層面看,貝葉斯網絡克服了馬爾科夫那種機械的線性的約束,它可以把任何有關聯的事件統一到它的框架下面。在網絡中,假定馬爾科夫假設成立,即每一個狀態只與和它直接相連的狀態有關,而和他間接相連的狀態沒有直接關系,那么它就是貝葉斯網絡。在網絡中每個節點概率的計算,都可以用貝葉斯公式來進行,貝葉斯網絡也因此得名。由于網絡的每個弧都有一個可信度,貝葉斯網絡也被稱作信念網絡(Belief Networks)。
            46.    條件隨機場是計算聯合概率分布的有效模型。在一個隱含馬爾科夫模型中,以x1,x2,...,xn表示觀測值序列,以y1,y2,...,yn表示隱含的狀態序列,那么xi只取決于產生它們的狀態yi,和前后的狀態yi-1和yi+1都無關。顯然很多應用里觀察值xi可能和前后的狀態都有關,如果把xi和yi-1,yi,yi+1都考慮進來,這樣的模型就是條件隨機場。它是一種特殊的概率圖模型(Probablistic Graph Model),它的特殊性在于,變量之間要遵守馬爾科夫假設,即每個狀態的轉移概率只取決于相鄰的狀態,這一點和另一種概率圖模型貝葉斯網絡相同,它們的不同之處在于條件隨機場是無向圖,而貝葉斯網絡是有向圖。
            47.    維特比算法(Viterbi Algoritm)是一個特殊但應用最廣的動態規劃算法,利用動態規劃,可以解決任何一個圖中的最短路徑問題。它之所以重要,是因為凡是使用隱含馬爾科夫模型描述的問題都可以用它來解碼。1.從點S出發,對于第一個狀態x1的各個節點,不妨假定有n1個,計算出S到他們的距離d(S,x1i),其中x1i代表任意狀態1的節點。因為只有一步,所以這些距離都是S到他們各自的最短距離。2.對于第二個狀態x2的所有節點,要計算出從S到他們的最短距離。d(S,x2i)=min_I=1,n1_d(S,x1j)+d(x1j,x2i),由于j有n1種可能性,需要一一計算,然后找到最小值。這樣對于第二個狀態的每個節點,需要n1次乘法計算。假定這個狀態有n2個節點,把S這些節點的距離都算一遍,就有O(n1*n2)次運算。3.按照上述方法從第二個狀態走到第三個狀態一直走到最后一個狀態,這樣就得到整個網絡從頭到尾的最短路徑。
            48.    擴頻傳輸(Spread-Spectrum Transmission)和固定頻率的傳輸相比,有三點明顯的好處:1.抗干擾能力強。2.信號能量非常低,很難獲取。3.擴頻傳輸利用帶寬更充分。
            49.    Google針對云計算給出的解決工具是MapReduce,其根本原理就是計算機算法上常見的分治算法(Divide-and-Conquer)。將一個大任務拆分成小的子任務,并完成子任務的計算,這個過程叫Map,將中間結果合并成最終結果,這個過程叫Reduce。
            50.    邏輯回歸模型(Logistic Regression)是將一個事件出現的概率適應到一條邏輯曲線(Logistic Curve)上。典型的邏輯回歸函數:f(z)=e`z/e`z+1=1/1+e`-z。邏輯曲線是一條S型曲線,其特點是開始變化快,逐漸減慢,最后飽和。邏輯自回歸的好處是它的變量范圍從負無窮到正無窮,而值域范圍限制在0-1之間。因為值域的范圍在0-1之間,這樣邏輯回歸函數就可以和一個概率分別聯系起來了。因為自變量范圍在負無窮到正無窮之間,它就可以把信號組合起來,不論組合成多大或者多小的值,最后依然能得到一個概率分布。
            51.    期望最大化算法(Expectation Maximization Algorithm),根據現有的模型,計算各個觀測數據輸入到模型中的計算結果,這個過程稱為期望值計算過程(Expectation),或E過程;接下來,重新計算模型參數,以最大化期望值,這個過程稱為最大化的過程(Maximization),或M過程。這一類算法都稱為EM算法,比如隱含馬爾科夫模型的訓練方法Baum-Welch算法,以及最大熵模型的訓練方法GIS算法。

            本文轉自:http://www.shnenglu.com/humanchao
            posted @ 2012-09-21 17:50 王海光 閱讀(1264) | 評論 (0)編輯 收藏
                 摘要: 一、預備知識—程序的內存分配
            一個由c/C++編譯的程序占用的內存分為以下幾個部分
            1、棧區(stack)— 由編譯器自動分配釋放 ,存放函數的參數值,局部變量的值等。其操作方式類似于數據結構中的棧。
            2、堆區(heap) — 一般由程序員分配釋放, 若程序員不釋放,程序結束時可能由OS回收 。注意它與數據結構中的堆是兩回事,分配方式倒是類似于鏈表,呵呵。
            3、全局區(靜態區)(static)—,全局變量和靜態變量的存儲是放在一塊的,初始化的全局變量和靜態變量在一塊區域, 未初始化的全局變量和未初始化的靜態變量在相鄰的另一塊區域。 - 程序結束后有系統釋放
            4、文字常量區—常量字符串就是放在這里的。 程序結束后由系統釋放
            5、程序代碼區—存放函數體的二進制代碼。
              閱讀全文
            posted @ 2012-09-21 13:04 王海光 閱讀(527) | 評論 (0)編輯 收藏

            author : Kevin Lynx

             

            什么是完成包?

            完成包,即IO Completion Packet,是指異步IO操作完畢后OS提交給應用層的通知包。IOCP維護了一個IO操作結果隊列,里面
            保存著各種完成包。應用層調用GQCS(也就是GetQueueCompletionStatus)函數獲取這些完成包。

            最大并發線程數

            在一個典型的IOCP程序里,會有一些線程調用GQCS去獲取IO操作結果。最大并發線程數指定在同一時刻處理完成包的線程數目。
            該參數在調用CreateIoCompletionPort時由NumberOfConcurrentThreads指定。

            工作者線程

            工作者線程一般指的就是調用GQCS函數的線程。要注意的是,工作者線程數和最大并發線程數并不是同一回事(見下文)。工作者
            線程由應用層顯示創建(_beginthreadex 之類)。工作者線程通常是一個循環,會不斷地GQCS到完成包,然后處理完成包。

            調度過程

            工作者線程以是否阻塞分為兩種狀態:運行狀態和等待狀態。當線程做一些阻塞操作時(線程同步,甚至GQCS空的完成隊列),線程
            處于等待狀態;否則,線程處于運行狀態。

            另一方面,OS會始終保持某一時刻處于運行狀態的線程數小于最大并發線程數。每一個調用GQCS函數的線程OS實際上都會進行記錄,
            當完成隊列里有完成包時,OS會首先檢查當前處于運行狀態的工作線程數是否小于最大并發線程數,如果小于,OS會按照LIFO的順
            序讓某個工作者線程從GQCS返回(此工作者線程轉換為運行狀態)。如何決定這個LIFO?這是簡單地通過調用GQCS函數的順序決定的。

            從這里可以看出,這里涉及到線程喚醒和睡眠的操作。如果兩個線程被放置于同一個CPU上,就會有線程切換的開銷。因此,為了消
            除這個開銷,最大并發線程數被建議為設置成CPU數量。

            從以上調度過程還可以看出,如果某個處于運行狀態的工作者線程在處理完成包時阻塞了(例如線程同步、其他IO操作),那么就有
            CPU資源處于空閑狀態。因此,我們也看到很多文檔里建議,工作者線程數為(CPU數*2+2)。

            在一個等待線程轉換到運行狀態時,有可能會出現短暫的時間運行線程數超過最大并發線程數,這個時候OS會迅速地讓這個新轉換
            的線程阻塞,從而減少這個數量。(關于這個觀點,MSDN上只說:by not allowing any new active threads,卻沒說明not allowing
            what)

            調度原理

            這個知道了其實沒什么意義,都是內核做的事,大致上都是操作線程control block,直接摘錄<Inside IO Completion Ports>:

            The list of threads hangs off the queue object. A thread's control block data structure has a pointer in it that
            references the queue object of a queue that it is associated with; if the pointer is NULL then the thread is not
            associated with a queue.

            So how does NT keep track of threads that become inactive because they block on something other than the completion
            port" The answer lies in the queue pointer in a thread's control block. The scheduler routines that are executed
            in response to a thread blocking (KeWaitForSingleObject, KeDelayExecutionThread, etc.) check the thread's queue
            pointer and if its not NULL they will call KiActivateWaiterQueue, a queue-related function. KiActivateWaiterQueue
            decrements the count of active threads associated with the queue, and if the result is less than the maximum and
            there is at least one completion packet in the queue then the thread at the front of the queue's thread list is
            woken and given the oldest packet. Conversely, whenever a thread that is associated with a queue wakes up after
            blocking the scheduler executes the function KiUnwaitThread, which increments the queue's active count.

            參考資料

            <Inside I/O Completion Ports>:
            http://technet.microsoft.com/en-us/sysinternals/bb963891.aspx
            <I/O Completion Ports>:
            http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx
            <INFO: Design Issues When Using IOCP in a Winsock Server>:
            http://support.microsoft.com/kb/192800/en-us/

            本文轉自:http://www.shnenglu.com/kevinlynx/archive/2008/06/23/54390.html

            posted @ 2012-09-20 13:12 王海光 閱讀(501) | 評論 (0)編輯 收藏

            Author : Kevin Lynx

            主要部分,四次握手:

            斷開連接其實從我的角度看不區分客戶端和服務器端,任何一方都可以調用close(or closesocket)之類
            的函數開始主動終止一個連接。這里先暫時說正常情況。當調用close函數斷開一個連接時,主動斷開的
            一方發送FIN(finish報文給對方。有了之前的經驗,我想你應該明白我說的FIN報文時什么東西。也就是
            一個設置了FIN標志位的報文段。FIN報文也可能附加用戶數據,如果這一方還有數據要發送時,將數據附
            加到這個FIN報文時完全正常的。之后你會看到,這種附加報文還會有很多,例如ACK報文。我們所要把握
            的原則是,TCP肯定會力所能及地達到最大效率,所以你能夠想到的優化方法,我想TCP都會想到。

            當被動關閉的一方收到FIN報文時,它會發送ACK確認報文(對于ACK這個東西你應該很熟悉了)。這里有個
            東西要注意,因為TCP是雙工的,也就是說,你可以想象一對TCP連接上有兩條數據通路。當發送FIN報文
            時,意思是說,發送FIN的一端就不能發送數據,也就是關閉了其中一條數據通路。被動關閉的一端發送
            了ACK后,應用層通常就會檢測到這個連接即將斷開,然后被動斷開的應用層調用close關閉連接。

            我可以告訴你,一旦當你調用close(or closesocket),這一端就會發送FIN報文。也就是說,現在被動
            關閉的一端也發送FIN給主動關閉端。有時候,被動關閉端會將ACK和FIN兩個報文合在一起發送。主動
            關閉端收到FIN后也發送ACK,然后整個連接關閉(事實上還沒完全關閉,只是關閉需要交換的報文發送
            完畢),四次握手完成。如你所見,因為被動關閉端可能會將ACK和FIN合到一起發送,所以這也算不上
            嚴格的四次握手---四個報文段。

            在前面的文章中,我一直沒提TCP的狀態轉換。在這里我還是在猶豫是不是該將那張四處通用的圖拿出來,
            不過,這里我只給出斷開連接時的狀態轉換圖,摘自<The TCP/IP Guide>:

             

            給出一個正常關閉時的windump信息:

            14:00:38.819856 IP cd-zhangmin.1748 > 220.181.37.55.80: F 1:1(0) ack 1 win 65535
            14:00:38.863989 IP 220.181.37.55.80 > cd-zhangmin.1748: F 1:1(0) ack 2 win 2920
            14:00:38.864412 IP cd-zhangmin.1748 > 220.181.37.55.80: . ack 2 win 65535 

             

            補充細節:

            關于以上的四次握手,我補充下細節:
            1. 默認情況下(不改變socket選項),當你調用close( or closesocket,以下說close不再重復)時,如果
            發送緩沖中還有數據,TCP會繼續把數據發送完。
            2. 發送了FIN只是表示這端不能繼續發送數據(應用層不能再調用send發送),但是還可以接收數據。
            3. 應用層如何知道對端關閉?通常,在最簡單的阻塞模型中,當你調用recv時,如果返回0,則表示對端
            關閉。在這個時候通常的做法就是也調用close,那么TCP層就發送FIN,繼續完成四次握手。如果你不調用
            close,那么對端就會處于FIN_WAIT_2狀態,而本端則會處于CLOSE_WAIT狀態。這個可以寫代碼試試。
            4. 在很多時候,TCP連接的斷開都會由TCP層自動進行,例如你CTRL+C終止你的程序,TCP連接依然會正常關
            閉,你可以寫代碼試試。

            特別的TIME_WAIT狀態:

            從以上TCP連接關閉的狀態轉換圖可以看出,主動關閉的一方在發送完對對方FIN報文的確認(ACK)報文后,
            會進入TIME_WAIT狀態。TIME_WAIT狀態也稱為2MSL狀態。

            什么是2MSL?MSL即Maximum Segment Lifetime,也就是報文最大生存時間,引用<TCP/IP詳解>中的話:“
            它(MSL)是任何報文段被丟棄前在網絡內的最長時間。”那么,2MSL也就是這個時間的2倍。其實我覺得沒
            必要把這個MSL的確切含義搞明白,你所需要明白的是,當TCP連接完成四個報文段的交換時,主動關閉的
            一方將繼續等待一定時間(2-4分鐘),即使兩端的應用程序結束。你可以寫代碼試試,然后用netstat查看下。

            為什么需要2MSL?根據<TCP/IP詳解>和<The TCP/IP Guide>中的說法,有兩個原因:
            其一,保證發送的ACK會成功發送到對方,如何保證?我覺得可能是通過超時計時器發送。這個就很難用
            代碼演示了。
            其二,報文可能會被混淆,意思是說,其他時候的連接可能會被當作本次的連接。直接引用<The TCP/IP Guide>
            的說法:The second is to provide a “buffering period” between the end of this connection
            and any subsequent ones. If not for this period, it is possible that packets from different
            connections could be mixed, creating confusion.

            TIME_WAIT狀態所帶來的影響:

            當某個連接的一端處于TIME_WAIT狀態時,該連接將不能再被使用。事實上,對于我們比較有現實意義的
            是,這個端口將不能再被使用。某個端口處于TIME_WAIT狀態(其實應該是這個連接)時,這意味著這個TCP
            連接并沒有斷開(完全斷開),那么,如果你bind這個端口,就會失敗。

            對于服務器而言,如果服務器突然crash掉了,那么它將無法再2MSL內重新啟動,因為bind會失敗。解決這
            個問題的一個方法就是設置socket的SO_REUSEADDR選項。這個選項意味著你可以重用一個地址。

            對于TIME_WAIT的插曲:

            當建立一個TCP連接時,服務器端會繼續用原有端口監聽,同時用這個端口與客戶端通信。而客戶端默認情況
            下會使用一個隨機端口與服務器端的監聽端口通信。有時候,為了服務器端的安全性,我們需要對客戶端進行
            驗證,即限定某個IP某個特定端口的客戶端。客戶端可以使用bind來使用特定的端口。

            對于服務器端,當設置了SO_REUSEADDR選項時,它可以在2MSL內啟動并listen成功。但是對于客戶端,當使
            用bind并設置SO_REUSEADDR時,如果在2MSL內啟動,雖然bind會成功,但是在windows平臺上connect會失敗。
            而在linux上則不存在這個問題。(我的實驗平臺:winxp, ubuntu7.10)

            要解決windows平臺的這個問題,可以設置SO_LINGER選項。SO_LINGER選項決定調用close時,TCP的行為。
            SO_LINGER涉及到linger結構體,如果設置結構體中l_onoff為非0,l_linger為0,那么調用close時TCP連接
            會立刻斷開,TCP不會將發送緩沖中未發送的數據發送,而是立即發送一個RST報文給對方,這個時候TCP連
            接就不會進入TIME_WAIT狀態。

            如你所見,這樣做雖然解決了問題,但是并不安全。通過以上方式設置SO_LINGER狀態,等同于設置SO_DONTLINGER
            狀態。

            斷開連接時的意外:
            這個算不上斷開連接時的意外,當TCP連接發生一些物理上的意外情況時,例如網線斷開,linux上的TCP實現
            會依然認為該連接有效,而windows則會在一定時間后返回錯誤信息。

            這似乎可以通過設置SO_KEEPALIVE選項來解決,不過不知道這個選項是否對于所有平臺都有效。

            總結:

            個人感覺,越寫越爛。接下來會講到TCP的數據發送,這會涉及到滑動窗口各種定時器之類的東西。我真誠
            希望各位能夠多提意見。對于TCP連接的斷開,我們只要清楚:
            1. 在默認情況下,調用close時TCP會繼續將數據發送完畢;
            2. TIME_WAIT狀態會導致的問題;
            3. 連接意外斷開時可能會出現的問題。
            4. maybe more...

            本文轉自:http://www.shnenglu.com/kevinlynx/archive/2008/05/14/49825.html

            posted @ 2012-09-20 13:00 王海光 閱讀(515) | 評論 (0)編輯 收藏

            Author : Kevin Lynx

            準備:

            在這里本文將遵循上一篇文章的風格,只提TCP協議中的要點,這樣我覺得可以更容易地掌握TCP。或者
            根本談不上掌握,對于這種純理論的東西,即使你現在掌握了再多的細節,一段時間后也會淡忘。

            在以后各種細節中,因為我們會涉及到分析一些TCP中的數據報,因此一個協議包截獲工具必不可少。在
            <TCP/IP詳解>中一直使用tcpdump。這里因為我的系統是windows,所以只好使用windows平臺的tcpdump,
            也就是WinDump。在使用WinDump之前,你需要安裝該程序使用的庫WinpCap

            關于WinDump的具體用法你可以從網上其他地方獲取,這里我只稍微提一下。要讓WinDump開始監聽數據,
            首先需要確定讓其監聽哪一個網絡設備(或者說是網絡接口)。你可以:

            windump -D

            獲取當前機器上的網絡接口。然后使用:

            windump -i 2 

            開始對網絡接口2的數據監聽。windump如同tcpdump(其實就是tcpdump)一樣支持過濾表達式,windump
            將會根據你提供的過濾表達式過濾不需要的網絡數據包,例如:

            windump -i 2 port 4000 

            那么windump只會顯示端口號為4000的網絡數據。

            序號和確認號:

            要講解TCP的建立過程,也就是那個所謂的三次握手,就會涉及到序號和確認號這兩個東西。翻書到TCP
            的報文頭,有兩個很重要的域(都是32位)就是序號域和確認號域。可能有些同學會對TCP那個報文頭有所
            疑惑(能看懂我在講什么的會產生這樣的疑惑么?),這里我可以告訴你,你可以假想TCP的報文頭就是個
            C語言結構體(假想而已,去翻翻bsd對TCP的實現,肯定沒這么簡單),那么大致上,所謂的TCP報文頭就是:

            typedef struct _tcp_header
            {
               
            /// 16位源端口號
                unsigned short src_port;
               
            /// 16位目的端口號
                unsigned short dst_port;
               
            /// 32位序號
                unsigned long seq_num;
               
            /// 32位確認號
                unsigned long ack_num;
               
            /// 16位標志位[4位首部長度,保留6位,ACK、SYN之類的標志位]
                unsigned short flag;
               
            /// 16位窗口大小
                unsigned short win_size;
               
            /// 16位校驗和
                short crc_sum;
               
            /// 16位緊急指針
                short ptr;
               
            /// 可選選項
               
            /// how to implement this ?   

            }
            tcp_header;

            那么,這個序號和確認號是什么?TCP報文為每一個字節都設置一個序號,覺得很奇怪?這里并不是為每一
            字節附加一個序號(那會是多么可笑的編程手法?),而是為一個TCP報文附加一個序號,這個序號表示報文
            中數據的第一個字節的序號,而其他數據則是根據離第一個數據的偏移來決定序號的,例如,現在有數據:
            abcd。如果這段數據的序號為1200,那么a的序號就是1200,b的序號就是1201。而TCP發送的下一個數據包
            的序號就會是上一個數據包最后一個字節的序號加一。例如efghi是abcd的下一個數據包,那么它的序號就
            是1204。通過這種看似簡單的方法,TCP就實現了為每一個字節設置序號的功能(終于明白為什么書上要告訴
            我們‘為每一個字節設置一個序號’了吧?)。注意,設置序號是一種可以讓TCP成為’可靠協議‘的手段。
            TCP中各種亂七八糟的東西都是有目的的,大部分目的還是為了’可靠‘兩個字。別把TCP看高深了,如果
            讓你來設計一個網絡協議,目的需要告訴你是’可靠的‘,你就會明白為什么會產生那些亂七八糟的東西了。

            接著看,確認號是什么?因為TCP會對接收到的數據包進行確認,發送確認數據包時,就會設置這個確認號,
            確認號通常表示接收方希望接收到的下一段報文的序號。例如某一次接收方收到序號為1200的4字節數舉報,
            那么它發送確認報文給發送方時,就會設置確認號為1204。

            大部分書上在講確認號和序號時,都會說確認號是序號加一。這其實有點誤解人,所以我才在這里廢話了
            半天(高手寬容下:D)。

            開始三次握手:

            如果你還不會簡單的tcp socket編程,我建議你先去學學,這就好比你不會C++基本語法,就別去研究vtable
            之類。

            三次握手開始于客戶端試圖連接服務器端。當你調用諸如connect的函數時,正常情況下就會開始三次握手。
            隨便在網上找張三次握手的圖:

            connection

            如前文所述,三次握手也就是產生了三個數據包。客戶端主動連接,發送SYN被設置了的報文(注意序號和
            確認號,因為這里不包含用戶數據,所以序號和確認號就是加一減一的關系)。服務器端收到該報文時,正
            常情況下就發送SYN和ACK被設置了的報文作為確認,以及告訴客戶端:我想打開我這邊的連接(雙工)。客戶
            端于是再對服務器端的SYN進行確認,于是再發送ACK報文。然后連接建立完畢。對于阻塞式socket而言,你
            的connect可能就返回成功給你。

            在進行了鋪天蓋地的羅利巴索的基礎概念的講解后,看看這個連接建立的過程,是不是簡單得幾近無聊?

            我們來實際點,寫個最簡單的客戶端代碼:

               sockaddr_in addr;
                memset(
            &addr, 0, sizeof( addr ) );
                addr.sin_family
            = AF_INET;
                addr.sin_port
            = htons( 80 );
               
            /// 220.181.37.55
                addr.sin_addr.s_addr = inet_addr( "220.181.37.55" );
                printf(
            "%s : connecting to server.\n", _str_time() );
               
            int err = connect( s, (sockaddr*) &addr, sizeof( addr ) );

            主要就是connect。運行程序前我們運行windump:

            windump -i 2 host 220.181.37.55 

             

            00:38:22.979229 IP noname.domain.4397 > 220.181.37.55.80: S 2523219966:2523219966(0) win 65535 <mss 1460,nop,nop,sackOK>
            00:38:23.024254 IP 220.181.37.55.80 > noname.domain.4397: S 1277008647:1277008647(0) ack 2523219967 win 2920 <mss 1440,nop,nop,sackOK>
            00:38:23.024338 IP noname.domain.4397 > 220.181.37.55.80: . ack 1 win 65535 

            如何分析windump的結果,建議參看<tcp/ip詳解>中對于tcpdump的描述。

            建立連接的附加信息:

            雖然SYN、ACK之類的報文沒有用戶數據,但是TCP還是附加了其他信息。最為重要的就是附加的MSS值。這個
            可以被協商的MSS值基本上就只在建立連接時協商。如以上數據表示,MSS為1460字節。

            連接的意外:

            連接的意外我大致分為兩種情況(也許還有更多情況):目的主機不可達、目的主機并沒有在指定端口監聽。
            當目的主機不可達時,也就是說,SYN報文段根本無法到達對方(如果你的機器根本沒插網線,你就不可達),
            那么TCP收不到任何回復報文。這個時候,你會看到TCP中的定時器機制出現了。TCP對發出的SYN報文進行
            計時,當在指定時間內沒有得到回復報文時,TCP就會重傳剛才的SYN報文。通常,各種不同的TCP實現對于
            這個超時值都不同,但是據我觀察,重傳次數基本上都是3次。例如,我連接一個不可達的主機:

            12:39:50.560690 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>
            12:39:53.538734 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>
            12:39:59.663726 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>

            發出了三個序號一樣的SYN報文,但是沒有得到一個回復報文(廢話)。每一個SYN報文之間的間隔時間都是
            有規律的,在windows上是3秒6秒9秒12秒。上面的數據你看不到12秒這個數據,因為這是第三個報文發出的
            時間和connect返回錯誤信息時的時間之差。另一方面,如果連接同一個網絡,這個間隔時間又不同。例如
            直接連局域網,間隔時間就差不多為500ms。

            (我強烈建議你能運行windump去試驗這里提到的每一個現象,如果你在ubuntu下使用tcpdump,記住sudo :D)

            出現意外的第二種情況是如果主機數據包可達,但是試圖連接的端口根本沒有監聽,那么發送SYN報文的這
            方會收到RST被設置的報文(connect也會返回相應的信息給你),例如:

            13:37:22.202532 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
            13:37:22.202627 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 2417354282 win 0
            13:37:22.711415 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
            13:37:22.711498 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 1 win 0
            13:37:23.367733 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
            13:37:23.367826 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 1 win 0 

            可以看出,7AURORA-CCTEST.7100返回了RST報文給我,但是我這邊根本不在乎這個報文,繼續發送SYN報文。
            三次過后connect就返回了。(數據反映的事實是這樣)

            關于listen:

            TCP服務器端會維護一個新連接的隊列。當新連接上的客戶端三次握手完成時,就會將其放入這個隊列。這個隊

            列的大小是通過listen設置的。當這個隊列滿時,如果有新的客戶端試圖連接(發送SYN),服務器端丟棄報文,

            同時不做任何回復。

            總結:
            TCP連接的建立的相關要點就是這些(or more?)。正常情況下就是三次握手,非正常情況下就是SYN三次超時,
            以及收到RST報文卻被忽略。

            本文轉自:http://www.shnenglu.com/kevinlynx/archive/2008/05/11/49482.html

            posted @ 2012-09-20 12:56 王海光 閱讀(418) | 評論 (0)編輯 收藏
                 摘要: 考慮一下多線程代碼,在設計上,App為了獲取更多的功能,從Window派生,而App同時為了獲取某個模塊的回調(所謂的Listener),App同時派生Listener,并將自己的指針交給另一個模塊,另一個模塊通過該指針多態回調到App的實現(對Listener規定的接口的implemention)。設計上只是一個很簡單的Listener回調,在單線程模式下一切都很正常(后面我會羅列代碼),但是換...  閱讀全文
            posted @ 2012-09-14 16:16 王海光 閱讀(719) | 評論 (0)編輯 收藏
            僅列出標題
            共27頁: First 12 13 14 15 16 17 18 19 20 Last 
            91精品国产高清91久久久久久| 久久这里只精品国产99热| 亚洲狠狠婷婷综合久久久久| 91精品国产91久久综合| 国产—久久香蕉国产线看观看| 久久人人爽人人爽人人片AV东京热| 久久精品国产免费观看三人同眠| 97久久精品无码一区二区| 久久无码国产| 青草影院天堂男人久久| 久久综合噜噜激激的五月天| 欧美国产成人久久精品| 久久精品一区二区三区不卡| 亚洲日韩欧美一区久久久久我| 国产精品99久久99久久久| 亚洲伊人久久综合影院| 国产精品成人久久久久久久| 久久久无码一区二区三区| 色综合久久夜色精品国产| 久久久中文字幕| 久久精品人人做人人爽电影蜜月| 中文字幕无码av激情不卡久久| 亚洲狠狠综合久久| 久久久噜噜噜久久熟女AA片| 久久久久久精品免费看SSS | 亚洲国产另类久久久精品| 国产精品免费久久久久久久久| 精品无码久久久久国产| 精品国产乱码久久久久软件| 久久国产香蕉视频| 国内精品久久久久久不卡影院| 国产亚洲美女精品久久久久狼| 日韩AV无码久久一区二区 | 一本久久a久久精品亚洲| 91麻豆精品国产91久久久久久| 国产精品久久久久久一区二区三区 | 久久久国产打桩机| 久久青青草原亚洲av无码| 久久久久久久亚洲精品| 国产精品成人99久久久久 | 欧美日韩成人精品久久久免费看|