• <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>

            Error

            C++博客 首頁 新隨筆 聯系 聚合 管理
              217 Posts :: 61 Stories :: 32 Comments :: 0 Trackbacks
            TCP之選項TCP_KETEPALIVE
             
            KEEPALIVE機制,是TCP協議規定的TCP層(非應用層業務代碼實現的)檢測TCP本端到對方主機的TCP連接的連通性的行為。避免服務器在客戶端出現各種不良狀況時無法感知,而永遠等在這條TCP連接上。
             
            該選項可以設置這個檢測行為的細節,如下代碼所示:
            int keepAlive = 1;    // 非0值,開啟keepalive屬性
            int keepIdle = 60;    // 如該連接在60秒內沒有任何數據往來,則進行此TCP層的探測
            int keepInterval = 5; // 探測發包間隔為5秒
            int keepCount = 3;        // 嘗試探測的次數.如果第1次探測包就收到響應了,則后2次的不再發
            setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));
            setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));
            setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));
            setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));
             
            設置該選項后,如果60秒內在此套接口所對應連接的任一方向都沒有數據交換,TCP層就自動給對方發一個保活探測分節(keepalive probe)。這是一個對方必須響應的TCP分節。它會導致以下三種情況:
                對方接收一切正常:以期望的ACK響應。60秒后,TCP將重新開始下一輪探測。
                對方已崩潰且已重新啟動:以RST響應。套接口的待處理錯誤被置為ECONNRESET。
                對方無任何響應:比如客戶端那邊已經斷網,或者客戶端直接死機。以設定的時間間隔嘗試3次,無響應就放棄。套接口的待處理錯誤被置為ETIMEOUT。
             
            全局設置可更改/etc/sysctl.conf,加上:
            net.ipv4.tcp_keepalive_intvl = 5
            net.ipv4.tcp_keepalive_probes = 3
            net.ipv4.tcp_keepalive_time = 60
             
            在程序中表現為:
            阻塞模型下,當TCP層檢測到對端socket不再可用時,內核無法主動通知應用層出錯,只有應用層主動調用read()或者write()這樣的IO系統調用時,內核才會利用出錯來通知應用層。
            非阻塞模型下,select或者epoll會返回sockfd可讀,應用層對其進行讀取時,read()會報錯。
             
            一點經驗:
            實際上我們在做服務器程序的時候,對客戶端的保活探測基本上不依賴于這個TCP層的keepalive探測機制。
            而是我們自己做一套應用層的請求應答消息,在應用層實現這樣一個功能。



            在Window上遇到這個問題,最后發現貌似只支持:
                           // 設置KEEPALIVE (開啟檢測)
            int optval = 1;
            setsockopt(m_hSocket, SOL_SOCKET, SO_KEEPALIVE, (char *) &optval, sizeof(optval));


            然后實際斷開是在主動Recv或者Send調用后才觸發的
            posted on 2015-07-22 17:48 Enic 閱讀(235) 評論(0)  編輯 收藏 引用 所屬分類: 從零開始寫棋牌游戲平臺
            国产69精品久久久久9999| 久久精品卫校国产小美女| 国内精品久久久久久中文字幕| 久久久久久国产精品无码下载| 最新久久免费视频| AV无码久久久久不卡蜜桃| 午夜精品久久久久成人| 无码精品久久久久久人妻中字| 四虎国产精品免费久久5151| 国产精品一区二区久久精品涩爱| 漂亮人妻被黑人久久精品| 久久久久噜噜噜亚洲熟女综合| 亚洲午夜久久久久久久久电影网| 久久精品夜色噜噜亚洲A∨| 国产精品一区二区久久国产| 久久久中文字幕日本| 久久人人爽人人爽人人AV东京热 | 狠狠精品干练久久久无码中文字幕| 久久综合五月丁香久久激情| 国内精品久久久久| 色欲综合久久躁天天躁蜜桃| 亚洲?V乱码久久精品蜜桃 | 久久久久夜夜夜精品国产| 久久精品中文字幕一区| 午夜精品久久久内射近拍高清 | 青青草原精品99久久精品66| 久久亚洲精品国产亚洲老地址| 久久精品国产精品亚洲人人| 国产产无码乱码精品久久鸭| 欧美牲交A欧牲交aⅴ久久 | 久久精品国产亚洲av麻豆小说 | 97久久综合精品久久久综合| 亚洲精品乱码久久久久久| 国内精品伊人久久久久777| 国产精品99久久久精品无码| 欧美日韩精品久久免费| 久久久无码精品亚洲日韩蜜臀浪潮 | 国产精品亚洲美女久久久| 国产福利电影一区二区三区,免费久久久久久久精 | 午夜人妻久久久久久久久| 国产亚洲精久久久久久无码77777 国产亚洲精品久久久久秋霞 |