在網絡編程的時候使用非阻塞的connect

對於面向連接的socket類型(SOCK_STREAM,SOCK_SEQPACKET)在讀寫數據之前必須建立連接，首先服務器端socket必須在一個客戶端知道的地址進行監聽,也就是創建socket之後必須調用bind綁定到一個指定的地址，然後調用int listen(int sockfd, int backlog);進行監聽。此時服務器socket允許客戶端進行連接，backlog提示沒被accept的客戶連接請求隊列的大小，系統決定實際的值，最大值定義爲SOMAXCONN在頭文件<sys/socket.h>裏面。如果某種原因導致服務器端進程未及時accpet客戶連接而導致此隊列滿了的話則新的客戶端連接請求被拒絕(在工作中遇到過此情況，IONA ORBIX(CORBA中間件)由於沒有配置超時時間結果在WIFI網絡中傳輸數據出現異常情況一直阻塞而無機會調用accept接受新的客戶請求，於是最終隊列滿導致新的客戶連接被拒絕)。

　　調用listen之後當有客戶端連接到達的時候調用int accept(int sockfd, struct sockaddr *restrict addr, socklen_t *restrict len);接受客戶端連接建立起連接返回用於連接數據傳送的socket描述符，進行監聽的socket可以用於繼續監聽客戶端的連接請求，返回的socket描述符跟監聽的socket類型一致。如果addr不爲NULL,則客戶端發起連接請求的socket地址信息會通過addr進行返回。如果監聽的socket描述符爲阻塞模式則accept一直會阻塞直到有客戶發起連接請求，如果監聽的socket描述符爲非阻塞模式則如果當前沒有可用的客戶連接請求，則返回-1(errno設置爲EAGAIN)。可以使用select函數對監聽的socket描述符進行多路分離，如果有客戶連接請求則select將監聽的socket描述符設置爲可讀(注意，如果監聽的socket爲阻塞模式而使用select進行多路分離則可能造成select返回可讀但是調用accept會被阻塞住的情況，原因是在調用accept之前客戶端可能主動關閉連接或者發送RST異常關閉連接，因此select最好跟非阻塞socket搭配使用)。

　　客戶端調用int connect(int sockfd, const struct sockaddr *addr, socklen_t len);發起對服務器的socket的連接請求，如果客戶端socket描述符爲阻塞模式則會一直阻塞到連接建立或者連接失敗(注意阻塞模式的超時時間可能爲75秒到幾分鐘之間)，而如果爲非阻塞模式，則調用connect之後如果連接不能馬上建立則返回-1(errno設置爲EINPROGRESS，注意連接也可能馬上建立成功比如連接本機的服務器進程),如果沒有馬上建立返回，此時TCP的三路握手動作在背後繼續，而程序可以做其他的東西，然後調用select檢測非阻塞connect是否完成(此時可以指定select的超時時間，這個超時時間可以設置爲比connect的超時時間短)，如果select超時則關閉socket，然後可以嘗試創建新的socket重新連接，如果select返回非阻塞socket描述符可寫則表明連接建立成功，如果select返回非阻塞socket描述符既可讀又可寫則表明連接出錯(注意：這兒必須跟另外一種連接正常的情況區分開來，就是連接建立好了之後，服務器端發送了數據給客戶端，此時select同樣會返回非阻塞socket描述符既可讀又可寫，這時可以通過以下方法區分:
　　1.調用getpeername獲取對端的socket地址.如果getpeername返回ENOTCONN,表示連接建立失敗,然後用SO_ERROR調用getsockopt得到套接口描述符上的待處理錯誤;
　　2.調用read,讀取長度爲0字節的數據.如果read調用失敗,則表示連接建立失敗,而且read返回的errno指明瞭連接失敗的原因.如果連接建立成功,read應該返回0;
　　3.再調用一次connect.它應該失敗,如果錯誤errno是EISCONN,就表示套接口已經建立,而且第一次連接是成功的;否則,連接就是失敗的;
　　對於無連接的socket類型(SOCK_DGRAM)，客戶端也可以調用connect進行連接,此連接實際上並不建立類似SOCK_STREAM的連接，而僅僅是在本地保存了對端的地址，這樣後續的讀寫操作可以默認以連接的對端爲操作對象。

　　當對端機器crash或者網絡連接被斷開(比如路由器不工作，網線斷開等)，此時發送數據給對端然後讀取本端socket會返回ETIMEDOUT或者EHOSTUNREACH 或者ENETUNREACH(後兩個是中間路由器判斷服務器主機不可達的情況)。

　　當對端機器crash之後又重新啓動，然後客戶端再向原來的連接發送數據，因爲服務器端已經沒有原來的連接信息，此時服務器端回送RST給客戶端，此時客戶端讀本地端口返回ECONNRESET錯誤。

　　當服務器所在的進程正常或者異常關閉時，會對所有打開的文件描述符進行close，因此對於連接的socket描述符則會向對端發送FIN分節進行正常關閉流程。對端在收到FIN之後端口變得可讀，此時讀取端口會返回0表示到了文件結尾(對端不會再發送數據)。　

　　當一端收到RST導致讀取socket返回ECONNRESET，此時如果再次調用write發送數據給對端則觸發SIGPIPE信號，信號默認終止進程，如果忽略此信號或者從SIGPIPE的信號處理程序返回則write出錯返回EPIPE。

　　可以看出只有當本地端口主動發送消息給對端才能檢測出連接異常中斷的情況,搭配select進行多路分離的時候，socket收到RST或者FIN時候，select返回可讀(心跳消息就是用於檢測連接的狀態)。也可以使用socket的KEEPLIVE選項，依賴socket本身偵測socket連接異常中斷的情況。

　　發送socket數據有以下方法:

　　調用ssize_t send(int sockfd, const void *buf, size_t nbytes, int flags);，只能用於建立好了連接的socket(面向連接的SOCK_STREAM或者調用了connect的SOCK_DGRAM)。flags取值如下:

　　MSG_DONTROUTE 對數據不進行路由

　　MSG_DONTWAIT 不等待數據發送完成

　　MSG_EOR 數據包結尾

　　MSG_OOB 帶外數據

　　注意send函數成功返回並不代表對端一定收到了發送的消息，另外對於數據報協議如果發送的數據大於一個數據報長度則發送失敗(errno設置爲EMSGSIZE)。

linux 客戶端 Socket 非阻塞connect編程(正文)

linux 客戶端 Socket 非阻塞connect編程（正文）/*開發過程與源碼解析

　　開發測試環境：虛擬機CentOS，windows網絡調試助手
　　非阻塞模式有3種用途

　　1.三次握手同時做其他的處理。connect要花一個往返時間完成，從幾毫秒的局域網到幾百毫秒或幾秒的廣域網。這段時間可能有一些其他的處理要執行，比如數據準備，預處理等。
　　2.用這種技術建立多個連接。這在web瀏覽器中很普遍.
　　3.由於程序用select等待連接完成，可以設置一個select等待時間限制，從而縮短connect超時時間。多數實現中，connect的超時時間在75秒到幾分鐘之間。有時程序希望在等待一定時間內結束，使用非阻塞connect可以防止阻塞75秒，在多線程網絡編程中，尤其必要。例如有一個通過建立線程與其他主機進行socket通信的應用程序，如果建立的線程使用阻塞connect與遠程通信，當有幾百個線程併發的時候，由於網絡延遲而全部阻塞，阻塞的線程不會釋放系統的資源，同一時刻阻塞線程超過一定數量時候，系統就不再允許建立新的線程（每個進程由於進程空間的原因能產生的線程有限），如果使用非阻塞的connect，連接失敗使用select等待很短時間，如果還沒有連接後，線程立刻結束釋放資源，防止大量線程阻塞而使程序崩潰。

　　目前connect非阻塞編程的普遍思路是：
　　在一個TCP套接口設置爲非阻塞後，調用connect，connect會在系統提供的errno變量中返回一個EINRPOCESS錯誤，此時TCP的三路握手繼續進行。之後可以用select函數檢查這個連接是否建立成功。以下實驗基於unix網絡編程和網絡上給出的普遍示例，在經過大量測試之後，發現其中有很多方法，在linux中，並不適用。

　　我先給出了重要源碼的逐步分析，在最後給出完整的connect非阻塞源碼。
　　1.首先填寫套接字結構，包括遠程的ip，通信端口如下： */
　　struct sockaddr_in serv_addr;
　　serv_addr.sin_family=AF_INET;
　　serv_addr.sin_port=htons(9999);
　　serv_addr.sin_addr.s_addr = inet_addr("58.31.231.255"); //inet_addr轉換爲網絡字節序
　　bzero(&(serv_addr.sin_zero),8);

　　// 2.建立socket套接字：
　　if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1)
　　{
　　perror("socket creat error");
　　return 1;
　　}

　　// 3.將socket建立爲非阻塞，此時socket被設置爲非阻塞模式
　　flags = fcntl(sockfd,F_GETFL,0);//獲取建立的sockfd的當前狀態（非阻塞）
　　fcntl(sockfd,F_SETFL,flags|O_NONBLOCK);//將當前sockfd設置爲非阻塞
　　/*4. 建立connect連接，此時socket設置爲非阻塞，connect調用後，無論連接是否建立立即返回-1，同時將errno（包含errno.h就可以直接使用）設置爲EINPROGRESS, 表示此時tcp三次握手仍舊進行，如果errno不是EINPROGRESS，則說明連接錯誤，程序結束。
　　當客戶端和服務器端在同一臺主機上的時候，connect回馬上結束，並返回0；無需等待，所以使用goto函數跳過select等待函數，直接進入連接後的處理部分。*/

　　if ( ( n = connect( sockfd, ( struct sockaddr *)&serv_addr , sizeof(struct sockaddr)) ) < 0 )
　　{
　　if(errno != EINPROGRESS) return 1;
　　}

　　if(n==0)
　　{
　　printf("connect completed immediately");
　　goto done;
　　}

　　/* 5.設置等待時間，使用select函數等待正在後臺連接的connect函數，這裏需要說明的是使用select監聽socket描述符是否可讀或者可寫，如果只可寫，說明連接成功，可以進行下面的操作。如果描述符既可讀又可寫，分爲兩種情況，第一種情況是socket連接出現錯誤（不要問爲什麼，這是系統規定的，可讀可寫時候有可能是connect連接成功後遠程主機斷開了連接close(socket)），第二種情況是connect連接成功，socket讀緩衝區得到了遠程主機發送的數據。需要通過connect連接後返回給errno的值來進行判定，或者通過調用 getsockopt(sockfd,SOL_SOCKET,SO_ERROR,&error,&len); 函數返回值來判斷是否發生錯誤，這裏存在一個可移植性問題，在solaris中發生錯誤返回-1，但在其他系統中可能返回0.我首先按unix網絡編程的源碼進行實現。如下：*/

　　FD_ZERO(&rset);
　　FD_SET(sockfd,&rset);
　　wset = rset;
　　tval.tv_sec = 0;
　　tval.tv_usec = 300000;
　　int error;
　　socklen_t len;

　　if(( n = select(sockfd+1, &rset, &wset, NULL,&tval)) <= 0)
　　{
　　printf("time out connect error");
　　close(sockfd);
　　return -1;
　　}

　　If ( FD_ISSET(sockfd,&rset) || FD_ISSET(sockfd,&west) )
　　{
　　len = sizeof(error);
　　if( getsockopt(sockfd,SOL_SOCKET,SO_ERROR,&error,&len) <0)
　　return 1;
　　}

　　/* 這裏我測試了一下，按照unix網絡編程的描述，當網絡發生錯誤的時候，getsockopt返回-1，return -1，程序結束。網絡正常時候返回0，程序繼續執行。
　　可是我在linux下，無論網絡是否發生錯誤，getsockopt始終返回0，不返回-1，說明linux與unix網絡編程還是有些細微的差別。就是說當socket描述符可讀可寫的時候，這段代碼不起作用。不能檢測出網絡是否出現故障。
　　我測試的方法是，當調用connect後，sleep（2）休眠2秒，藉助這兩秒時間將網絡助手斷開連接，這時候select返回2，說明套接口可讀又可寫，應該是網絡連接的出錯情況。
　　此時，getsockopt返回0，不起作用。獲取errno的值，指示爲EINPROGRESS，沒有返回unix網絡編程中說的ENOTCONN，EINPROGRESS表示正在試圖連接，不能表示網絡已經連接失敗。
針對這種情況，unix網絡編程中提出了另外3種方法，這3種方法，也是網絡上給出的常用的非阻塞connect示例：
　　a.再調用connect一次。失敗返回errno是EISCONN說明連接成功，表示剛纔的connect成功，否則返回失敗。代碼如下：*/

　　int connect_ok;

　　connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(struct sockaddr) );
　　switch (errno)
　　{
　　case EISCONN: //connect ok
　　printf("connect OK \n");
　　connect_ok = 1;
　　break;
　　case EALREADY:
　　connect_0k = -1
　　break;
　　case EINPROGRESS: // is connecting, need to check again
　　connect_ok = -1
　　break;
　　default:
　　printf("connect fail err=%d \n",errno);
　　connect_ok = -1;
　　break;
　　}

　　/*如程序所示，根據再次調用的errno返回值將connect_ok的值，來進行下面的處理，connect_ok爲1繼續執行其他操作，否則程序結束。
　　但這種方法我在linux下測試了，當發生錯誤的時候,socket描述符（我的程序裏是sockfd）變成可讀且可寫，但第二次調用connect 後，errno並沒有返回EISCONN，,也沒有返回連接失敗的錯誤，仍舊是EINPROGRESS，而當網絡不發生故障的時候，第二次使用 connect連接也返回EINPROGRESS，因此也無法通過再次connect來判斷連接是否成功。
　　b.unix網絡編程中說使用read函數，如果失敗，表示connect失敗，返回的errno指明瞭失敗原因，但這種方法在linux上行不通，linux在socket描述符爲可讀可寫的時候，read返回0，並不會置errno爲錯誤。
　 c.unix網絡編程中說使用getpeername函數，如果連接失敗，調用該函數後，通過errno來判斷第一次連接是否成功，但我試過了，無論網絡連接是否成功，errno都沒變化，都爲EINPROGRESS，無法判斷。
　　悲哀啊，即使調用getpeername函數，getsockopt函數仍舊不行。
　　綜上方法，既然都不能確切知道非阻塞connect是否成功，所以我直接當描述符可讀可寫的情況下進行發送，通過能否獲取服務器的返回值來判斷是否成功。(如果服務器端的設計不發送數據，那就悲哀了。)
　　程序的書寫形式出於可移植性考慮，按照unix網絡編程推薦寫法，使用getsocketopt進行判斷，但不通過返回值來判斷，而通過函數的返回參數來判斷。
　　6. 用select查看接收描述符，如果可讀，就讀出數據，程序結束。在接收數據的時候注意要先對先前的rset重新賦值爲描述符，因爲select會對 rset清零，當調用select後，如果socket沒有變爲可讀，則rset在select會被置零。所以如果在程序中使用了rset，最好在使用時候重新對rset賦值。

　　程序如下：*/

　　FD_ZERO(&rset);
　　FD_SET(sockfd,&rset);//如果前面select使用了rset，最好重新賦值

　　if( ( n = select(sockfd+1,&rset,NULL, NULL,&tval)) <= 0 )
　　{
　　close(sockfd);
　　return -1;
　　}

　　if ((recvbytes=recv(sockfd, buf, 1024, 0)) ==-1)
　　{
　　perror("recv error!");
　　close(sockfd);
　　return 1;

　　}
　　printf("receive num %d\n",recvbytes);

　　printf("%s\n",buf);

　　*/

非阻塞connect

在一個TCP套接口被設置爲非阻塞之後調用connect,connect會立即返回EINPROGRESS錯誤,表示連接操作正在進行中,但是仍未完成;同時TCP的三路握手操作繼續進行;在這之後,我們可以調用select來檢查這個鏈接是否建立成功;非阻塞connect有三種用途:
1.我們可以在三路握手的同時做一些其它的處理.connect操作要花一個往返時間完成,而且可以是在任何地方,從幾個毫秒的局域網到幾百毫秒或幾秒的廣域網.在這段時間內我們可能有一些其他的處理想要執行;
2.可以用這種技術同時建立多個連接.在Web瀏覽器中很普遍;
3.由於我們使用select來等待連接的完成,因此我們可以給select設置一個時間限制,從而縮短connect的超時時間.在大多數實現中,connect的超時時間在75秒到幾分鐘之間.有時候應用程序想要一個更短的超時時間,使用非阻塞connect就是一種方法;
非阻塞connect聽起來雖然簡單,但是仍然有一些細節問題要處理:
1.即使套接口是非阻塞的,如果連接的服務器在同一臺主機上,那麼在調用connect建立連接時,連接通常會立即建立成功.我們必須處理這種情況;
2.源自Berkeley的實現(和Posix.1g)有兩條與select和非阻塞IO相關的規則:
A:當連接建立成功時,套接口描述符變成可寫;
B:當連接出錯時,套接口描述符變成既可讀又可寫;
注意:當一個套接口出錯時,它會被select調用標記爲既可讀又可寫;

非阻塞connect有這麼多好處,但是處理非阻塞connect時會遇到很多可移植性問題;

處理非阻塞connect的步驟:
第一步:創建socket,返回套接口描述符;
第二步:調用fcntl把套接口描述符設置成非阻塞;
第三步:調用connect開始建立連接;
第四步:判斷連接是否成功建立;
       A:如果connect返回0,表示連接簡稱成功(服務器可客戶端在同一臺機器上時就有可能發生這種情況);
       B:調用select來等待連接建立成功完成;
         如果select返回0,則表示建立連接超時;我們返回超時錯誤給用戶,同時關閉連接,以防止三路握手操作繼續進行下去;
         如果select返回大於0的值,則需要檢查套接口描述符是否可讀或可寫;如果套接口描述符可讀或可寫,則我們可以通過調用getsockopt來得到套接口上待處理的錯誤(SO_ERROR),如果連接建立成功,這個錯誤值將是0,如果建立連接時遇到錯誤,則這個值是連接錯誤所對應的errno值(比如:ECONNREFUSED,ETIMEDOUT等).
"讀取套接口上的錯誤"是遇到的第一個可移植性問題;如果出現問題,getsockopt源自Berkeley的實現是返回0,等待處理的錯誤在變量errno中返回;但是Solaris會讓getsockopt返回-1,errno置爲待處理的錯誤;我們對這兩種情況都要處理;

這樣,在處理非阻塞connect時,在不同的套接口實現的平臺中存在的移植性問題,首先,有可能在調用select之前,連接就已經建立成功,而且對方的數據已經到來.在這種情況下,連接成功時套接口將既可讀又可寫.這和連接失敗時是一樣的.這個時候我們還得通過getsockopt來讀取錯誤值;這是第二個可移植性問題;
移植性問題總結:
1.對於出錯的套接口描述符,getsockopt的返回值源自Berkeley的實現是返回0,待處理的錯誤值存儲在errno中;而源自Solaris的實現是返回0,待處理的錯誤存儲在errno中;(套接口描述符出錯時調用getsockopt的返回值不可移植)
2.有可能在調用select之前,連接就已經建立成功,而且對方的數據已經到來,在這種情況下,套接口描述符是既可讀又可寫;這與套接口描述符出錯時是一樣的;(怎樣判斷連接是否建立成功的條件不可移植)

這樣的話,在我們判斷連接是否建立成功的條件不唯一時,我們可以有以下的方法來解決這個問題:
1.調用getpeername代替getsockopt.如果調用getpeername失敗,getpeername返回ENOTCONN,表示連接建立失敗,我們必須以SO_ERROR調用getsockopt得到套接口描述符上的待處理錯誤;
2.調用read,讀取長度爲0字節的數據.如果read調用失敗,則表示連接建立失敗,而且read返回的errno指明瞭連接失敗的原因.如果連接建立成功,read應該返回0;
3.再調用一次connect.它應該失敗,如果錯誤errno是EISCONN,就表示套接口已經建立,而且第一次連接是成功的;否則,連接就是失敗的;

被中斷的connect:
如果在一個阻塞式套接口上調用connect,在TCP的三路握手操作完成之前被中斷了,比如說,被捕獲的信號中斷,將會發生什麼呢?假定connect不會自動重啓,它將返回EINTR.那麼,這個時候,我們就不能再調用connect等待連接建立完成了,如果再次調用connect來等待連接建立完成的話,connect將會返回錯誤值EADDRINUSE.在這種情況下,應該做的是調用select,就像在非阻塞式connect中所做的一樣.然後,select在連接建立成功(使套接口描述符可寫)或連接建立失敗(使套接口描述符既可讀又可寫)時返回;

Linux網絡編程之connect函數分析

在一個 CLIENT/SERVER模型的網絡應用中，客戶端的調用序列大致如下：

socket -> connect -> recv/send -> close

其中socket沒有什麼可疑問的，主要是創建一個套接字用於與服務端交換數據，並且通常它會迅速返回，此時並沒有數據通過網卡發送出去，而緊隨其後的 connect函數則會產生網絡數據的發送，TCP的三次握手也正是在此時開始，connect會先發送一個SYN包給服務端，並從最初始的CLOSED 狀態進入到SYN_SENT狀態，在此狀態等待服務端的確認包，通常情況下這個確認包會很快到達，以致於我們根本無法使用netstat命令看到 SYN_SENT狀態的存在，不過我們可以做一個極端情況的模擬，讓客戶端去連接一個隨意指定服務器（如IP地址爲88.88.88.88），因爲該服務器很明顯不會反饋給我們SYN包的確認包(SYN ACK)，客戶端就會在一定時間內處於SYN_SENT狀態，並在預定的超時時間（比如3分鐘）之後從connect函數返回，connect調用一旦失敗(沒能到達ESTABLISHED狀態)這個套接字便不可用，若要再次調用connect函數則必須要重新使用socket函數創建新的套接字。

下面結合實例分析，客戶端代碼如下：