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

            大龍的博客

            常用鏈接

            統計

            最新評論

            send或者write socket遭遇SIGPIPE信號(轉)

            當服務器close一個連接時,若client端接著發數據。根據TCP協議的規定,會收到一個RST響應,client再往這個服務器發送數據時,系統會發出一個SIGPIPE信號給進程,告訴進程這個連接已經斷開了,不要再寫了。

            又或者當一個進程向某個已經收到RST的socket執行寫操作是,內核向該進程發送一個SIGPIPE信號。該信號的缺省學位是終止進程,因此進程必須捕獲它以免不情愿的被終止。


            根據信號的默認處理規則SIGPIPE信號的默認執行動作是terminate(終止、退出),所以client會退出。若不想客戶端退出可以把 SIGPIPE設為SIG_IGN

            如:signal(SIGPIPE, SIG_IGN);
            這時SIGPIPE交給了系統處理。

            服務器采用了fork的話,要收集垃圾進程,防止僵尸進程的產生,可以這樣處理:
            signal(SIGCHLD,SIG_IGN);
            交給系統init去回收。
            這里子進程就不會產生僵尸進程了。


            在linux下寫socket的程序的時候,如果嘗試send到一個disconnected socket上,就會讓底層拋出一個SIGPIPE信號。
            這個信號的缺省處理方法是退出進程,大多數時候這都不是我們期望的。因此我們需要重載這個信號的處理方法。調用以下代碼,即可安全的屏蔽SIGPIPE:
            struct sigaction sa;
            sa.sa_handler = SIG_IGN;
            sigaction( SIGPIPE, &sa, 0 );

            signal設置的信號句柄只能起一次作用,信號被捕獲一次后,信號句柄就會被還原成默認值了。
            sigaction設置的信號句柄,可以一直有效,值到你再次改變它的設置。

            struct sigaction action;
            action.sa_handler = handle_pipe;
            sigemptyset(&action.sa_mask);
            action.sa_flags = 0;
            sigaction(SIGPIPE, &action, NULL);
            void handle_pipe(int sig)
            {
                    //不做任何處理即可
            }

            RST的含義為“復位”,它是TCP在某些錯誤情況下所發出的一種TCP分節。有三個條件可以產生RST:

            1), SYN到達某端口但此端口上沒有正在監聽的服務器。
            2), TCP想取消一個已有連接
            3), TCP接收了一個根本不存在的連接上的分節。

            1. Connect 函數返回錯誤ECONNREFUSED:
            如果對客戶的SYN的響應是RST,則表明該服務器主機在我們指定的端口上沒有進程在等待與之連接(例如服務器進程也許沒有啟動),這稱為硬錯(hard error),客戶一接收到RST,馬上就返回錯誤ECONNREFUSED.

            TCP為監聽套接口維護兩個隊列。兩個隊列之和不超過listen函數第二個參數backlog。

            當 一個客戶SYN到達時,若兩個隊列都是滿的,TCP就忽略此分節,且不發送RST.這個因為:這種情況是暫時的,客戶TCP將重發SYN,期望不久就能在 隊列中找到空閑條目。要是TCP服務器發送了一個RST,客戶connect函數將立即發送一個錯誤,強制應用進程處理這種情況,而不是讓TCP正常的重 傳機制來處理。還有,客戶區別不了這兩種情況:作為SYN的響應,意為“此端口上沒有服務器”的RST和意為“有服務器在此端口上但其隊列滿”的 RST.
            Posix.1g允許以下兩種處理方法:忽略新的SYN,或為此SYN響應一個RST.歷史上,所有源自Berkeley的實現都是忽略新的SYN。

            2.如果殺掉服務器端處理客戶端的子進程,進程退出后,關閉它打開的所有文件描述符,此時,當服務器TCP接收到來自此客戶端的數據時,由于先前打開的那個套接字接口的進程已終止,所以以RST響應。

            經常遇到的問題:
            如果不判斷read , write函數的返回值,就不知道服務器是否響應了RST, 此時客戶端如果向接收了RST的套接口進行寫操作時,內核給該進程發一個SIGPIPE信號。此信號的缺省行為就是終止進程,所以,進程必須捕獲它以免不情愿地被終止。

            進程不論是捕獲了該信號并從其信號處理程序返回,還是不理會該信號,寫操作都返回EPIPE錯誤。


            3. 服務器主機崩潰后重啟
            如 果服務器主機與客戶端建立連接后崩潰,如果此時,客戶端向服務器發送數據,而服務器已經崩潰不能響應客戶端ACK,客戶TCP將持續重傳數據分節,試圖從 服務器上接收一個ACK,如果服務器一直崩潰客戶端會發現服務器已經崩潰或目的地不可達,但可能需要比較長的時間; 如果服務器在客戶端發現崩潰前重啟,服務器的TCP丟失了崩潰前的所有連接信息,所以服務器TCP對接收的客戶數據分節以RST響應。

            二、關于socket的recv:

            對于TCP non-blocking socket, recv返回值== -1,但是errno == EAGAIN, 此時表示在執行recv時相應的socket buffer中沒有數據,應該繼續recv。

            【If no messages are available at the socket and O_NONBLOCK is not set on the socket's file descriptor, recv() shall block until a message arrives. If no messages are available at the socket and O_NONBLOCK is set on the socket's file descriptor, recv() shall fail and set errno to [EAGAIN] or [EWOULDBLOCK].】

            對于UDP recv 應該一直讀取直到recv()==-1 && errno==EAGAIN,表示buffer中數據包被全部讀取。

             

             


                while(res != 0)
                {
                    
            //len = recv(sockfd, buff, MAXBUF, 0);


                    len =recv(sockfd, buff, 5, 0);
                    if(len < 0 ){
                        if(errno== EAGAIN){
                            printf("RE-Len:%d errno EAGAIN\n", len);
                            return 12;
                        }

                        if (errno == EINTR)

                           continue;          
                        perror("recv error\n");
                        break;
                    }elseif(len > 0){
                        printf("Recved:%s, and len is:%d \n", buff, len);
                        len =send(sockfd, buff, len, 0);/* if the client socket was closed and the socketfd here in kernel has set the status as RST this process will recv a SIGPIPE, and the process will exit if we don't handle it to SIGING */
                        if(len < 0){
                            perror("send error");
                            return-1;
                        }
                        memset(buff, 0, MAXBUF);
                        continue;
                    }else{
            //==0

                        printf("Disconnected by peer!\n");
                        res = 0;
                    }
                }



            外記:
            accetp()是慢系統調用,在信號產生時會中斷其調用并將errno變量設置為EINTR,此時應重新調用accept()。
            所以使用時應這樣:


             while(1){
              if((connfd =accept(....))==-1 ){
              if(errno== EINTR)
              continue;
              perror("accept()");
              exit(1);
              }


              /* do sth with "connfd" */
              }



            signal 與 sigaction 區別:
                signal函數每次設置具體的信號處理函數(非SIG_IGN)只能生效一次,每次在進程響應處理信號時,隨即將信號處理函數恢復為默認處理方式.所以如果想多次相同方式處理某個信號,通常的做法是,在響應函數開始,再次調用signal設置。

            int sig_int();//My signal handler

                ...
                signal(SIGINT, sig_int);
                ...

            int sig_int()
            {

               signal(SIGINT, sig_int);
                ....
            }

            這種代碼段的一個問題是:在信號發生之后到信號處理程序中調用s i g n a l函數之間有一個
            時間窗口。在此段時間中,可能發生另一次中斷信號。第二個信號會造成執行默認動作,而對
            中斷信號則是終止該進程。這種類型的程序段在大多數情況下會正常工作,使得我們認為它們
            正確,而實際上卻并不是如此。
            另一個問題是:在進程不希望某種信號發生時,它不能關閉該信號

            sigaction:
            1.在信號處理程序被調用時,系統建立的新信號屏蔽字會自動包括正被遞送的信號。因此保證了在處理一個
            給定的信號時,如果這種信號再次發生,那么它會被阻塞到對前一個信號的處理結束為止
            2.響應函數設置后就一直有效,不會重置
            3.對除S I G A L R M以外的所有信號都企圖設置S A _ R E S TA RT標志,于是被這些信號中斷
            的系統調用(read,write)都能自動再起動。不希望再起動由S I G A L R M信號中斷的系統調用的原因是希望對I / O操作可以設置時間限制。
             
            所以希望能用相同方式處理信號的多次出現,最好用sigaction.信號只出現并處理一次,可以用signal

            posted on 2011-11-05 01:13 大龍 閱讀(2292) 評論(0)  編輯 收藏 引用

            国产综合久久久久| 久久精品国产亚洲一区二区三区| 97久久超碰国产精品旧版| 中文字幕亚洲综合久久菠萝蜜| 久久精品国产免费| 久久精品男人影院| WWW婷婷AV久久久影片| 久久亚洲美女精品国产精品| 蜜臀久久99精品久久久久久小说 | 国产精品一久久香蕉国产线看观看| 色婷婷久久久SWAG精品| 亚洲国产成人精品无码久久久久久综合 | 99久久精品影院老鸭窝| 精品免费久久久久久久| 久久一日本道色综合久久| 亚洲乱码精品久久久久..| 欧美黑人又粗又大久久久| 国产综合久久久久久鬼色| 狠狠久久综合伊人不卡| 久久久久久国产a免费观看黄色大片 | 婷婷久久综合九色综合九七| 亚洲欧美一级久久精品| 欧洲人妻丰满av无码久久不卡| 精品久久久久久亚洲精品| 日韩一区二区久久久久久| 久久人人爽人人澡人人高潮AV| 麻豆精品久久久久久久99蜜桃 | 久久人人爽人人爽人人av东京热| 人妻无码αv中文字幕久久琪琪布| 99久久人妻无码精品系列蜜桃| 久久不见久久见免费视频7| 国产亚洲色婷婷久久99精品91| 日韩人妻无码一区二区三区久久99 | 亚洲精品乱码久久久久久久久久久久| 亚洲AV无码久久精品成人| 国产精品成人无码久久久久久| 亚洲国产日韩综合久久精品| 久久精品国产99国产精品澳门| 97视频久久久| 久久久久久国产精品无码下载| 国产精品美女久久久m|