新聞中心
在Linux環(huán)境下,connect函數(shù)通常被用于網(wǎng)絡編程中TCP協(xié)議的客戶端對服務器進行連接,然而,connect函數(shù)在連接失敗時會阻塞當前進程,這會帶來很多問題。在本文中,我將會介紹一些解決這個問題的方法。

1. 非阻塞connect
解決connect函數(shù)阻塞的一個簡單方法是使用非阻塞connect。在此過程中,sockfd會在連接失敗后立即返回,并設置errno為EINPROGRESS。這使得我們能夠立即處理其他事件,而不必等待connect執(zhí)行完成。我們可以使用select或epoll調(diào)用來檢查sockfd是否連接成功或失敗。
以下是一個使用非阻塞connect的示例:
“`
fcntl(sockfd, F_SETFL, O_NONBLOCK);
int rc = connect(sockfd, (struct sockaddr *)&addr, sizeof(addr));
if (rc
fd_set write_fds;
FD_ZERO(&write_fds);
FD_SET(sockfd, &write_fds);
rc = select(sockfd + 1, NULL, &write_fds, NULL, NULL);
if (rc
printf(“connect error or timeout\n”);
return -1;
}
}
“`
我們首先使用fcntl函數(shù)將sockfd設置為非阻塞模式。然后我們調(diào)用connect函數(shù),在連接失敗時,我們檢查errno是否為EINPROGRESS。如果是,我們使用select函數(shù)等待sockfd變?yōu)榭梢詫懭霠顟B(tài)。如果select返回0或小于0,則表示連接失敗。
使用非阻塞connect的缺點是需要更多的代碼來處理錯誤情況。另外,我們需要使用select或epoll函數(shù)來等待連接建立,這可能會影響性能。但是,非阻塞connect是一個簡單且經(jīng)典的解決方案,它可以使我們避免在連接失敗時長時間阻塞。
2. 使用SO_REUSEADDR選項
另一種解決connect函數(shù)阻塞的方法是使用SO_REUSEADDR選項。在默認情況下,如果一個進程在給定端口上啟動了一個服務,但是在關閉該服務之前,再次啟動相同的服務將失敗,因為該端口仍然在被占用。如果我們使用SO_REUSEADDR選項,即使之前的服務仍在運行,我們?nèi)匀豢梢越壎ㄍ粋€端口,這可以防止connect函數(shù)阻塞。
以下是一個使用SO_REUSEADDR選項的示例:
“`
int optval = 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));
int rc = connect(sockfd, (struct sockaddr *)&addr, sizeof(addr));
“`
我們首先使用setsockopt函數(shù)設置SO_REUSEADDR選項。然后,我們就可以直接使用connect函數(shù)了,它不再會阻塞進程。
使用SO_REUSEADDR選項的缺點是我們需要確保加鎖訪問該端口,以避免其他進程的干擾。另外,可能會出現(xiàn)端口錯誤的問題,因為我們不能確定該端口是否正在被占用。然而,對于某些情況,SO_REUSEADDR可能是一個非常有用的解決方案。
3. 使用異步DNS解析
當我們使用IP地址而不是主機名連接到服務器時,連接的速度通常會更快,因為不必經(jīng)過DNS解析。然而,如果我們需要使用主機名連接到服務器,我們可以使用異步DNS解析來避免connect函數(shù)阻塞。在此過程中,我們不會直接解析DNS,而是使用getaddrinfo函數(shù)來獲取服務器的地址。getaddrinfo函數(shù)將返回將服務器的地址封裝在結構體鏈表中。我們可以使用這個地址來連接服務器,而不必等待DNS解析完成。
以下是一個使用異步DNS解析的示例:
“`
struct addrinfo hints, *res;
memset(&hints, 0, sizeof(hints));
hints._family = AF_INET; //使用IPv4
hints._flags = _ADDRCONFIG | _NUMERICSERV;
getaddrinfo(host, port_str, &hints, &res);
int sockfd = socket(res->_family, SOCK_STREAM, 0);
connect(sockfd, res->_addr, res->_addrlen);
“`
我們首先使用getaddrinfo函數(shù)來解析DNS。這個函數(shù)將在后臺執(zhí)行,并將服務器的地址封裝在addrinfo結構體鏈表中。然后我們創(chuàng)建一個套接字并使用connect函數(shù)將其連接到服務器的地址。
使用異步DNS解析的優(yōu)點是我們不必等待DNS解析完成,因此可以避免connect函數(shù)阻塞。另外,這個方法還可以支持多個服務器,因為我們可以使用getaddrinfo函數(shù)解析多個主機名。缺點是需要更多的代碼來處理錯誤情況。另外,由于getaddrinfo函數(shù)在后臺運行,因此我們必須確保在連接之前等待DNS解析完成。
結論:
在本文中,我們介紹了三種解決connect函數(shù)阻塞的方法。非阻塞connect使用了select或epoll函數(shù)來等待連接建立;使用SO_REUSEADDR選項可以使我們在同一端口上重新啟動服務;異步DNS解析可以避免connect函數(shù)阻塞。這些方法各有優(yōu)缺點,我們應該根據(jù)我們的需求選擇合適的方法。最終目的是確保我們的程序不會因為connect函數(shù)阻塞而變慢或掛起。
成都網(wǎng)站建設公司-創(chuàng)新互聯(lián),建站經(jīng)驗豐富以策略為先導10多年以來專注數(shù)字化網(wǎng)站建設,提供企業(yè)網(wǎng)站建設,高端網(wǎng)站設計,響應式網(wǎng)站制作,設計師量身打造品牌風格,熱線:028-86922220linux網(wǎng)絡編程,為什么要將文件描述符設置成非阻塞模式
非阻塞IO 和阻塞IO:
在網(wǎng)絡編程中對于一個網(wǎng)絡句柄會遇到阻塞IO 和非阻塞IO 的概念, 這里對于這兩種socket 先做一下說明:
基本概念:
阻塞IO::
socket 的阻塞模式意味著必須要做完IO 操作(包括錯誤)才會
返回。
非阻塞IO::
非阻塞模式下無論操作是否完成都會立刻返回,需要通過其他方
式來判斷具體操作是否成功。(對于connect,accpet操作,通過select判斷,
對于recv,recvfrom,send,sendto通過返回值+錯誤碼來判斷)
IO模式設置:
SOCKET
對于一個socket 是阻塞模式還是非阻塞模式的處理方法::
方法::
用fcntl 設置;用F_GETFL獲取flags,用F_SETFL設置flags|O_NONBLOCK;
同時,recv,send 時使用非阻塞的方式讀取和發(fā)送消息,即flags設置為MSG_DONTWAIT
實現(xiàn)
fcntl 函數(shù)可以將一個socket 句柄設置成非阻塞模式:
flags = fcntl(sockfd, F_GETFL, 0);//獲取文件的flags值。
fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); //設置成非阻塞模式;
flags = fcntl(sockfd,F_GETFL,0);
fcntl(sockfd,F_SETFL,flags&~O_NONBLOCK); //設置成阻塞模式;
并在接收和發(fā)送數(shù)據(jù)時:
將recv, send 函數(shù)的最后有一個flag 參數(shù)設置成MSG_DONTWAIT
recv(sockfd, buff, buff_size,MSG_DONTWAIT); //非阻塞模式的消息仔租發(fā)送
send(scokfd, buff, buff_size, MSG_DONTWAIT); //非阻塞模式的消息接受
普通文件
對于文件的阻塞模式還是非阻塞模式::
方法1、open時,使用O_NONBLOCK;
方法2、fcntl設置,使用F_SETFL,flags|O_NONBLOCK;
消息隊列
對于消息隊列消息的發(fā)送與接受::
//非阻塞 msgsnd(sockfd,msgbuf,msgsize(不包含類型大小),IPC_NOWAIT)
//阻塞 msgrcv(scokfd,msgbuf,msgsize(**),msgtype,IPC_NOWAIT);
讀
阻塞與非阻塞讀的區(qū)別: //
阻塞和非阻塞
的區(qū)別在于沒有數(shù)據(jù)到達的時候是否立刻返回.
讀(read/recv/msgrcv):
讀的本質(zhì)來說其實不能是讀,在實際中, 具體的接收數(shù)據(jù)不是由這些調(diào)用來進行,是由于系統(tǒng)底層自動完成的。read 也好,recv 也好只負責把數(shù)據(jù)從底層緩沖copy 到我們指肢戚基定的位置.
對于讀來說(read, 或者recv) ::
阻塞情況下::
在阻塞條件下,read/recv/msgrcv的行為::
、如果沒有發(fā)現(xiàn)數(shù)據(jù)在網(wǎng)絡緩沖中會一直等待,
、當發(fā)現(xiàn)有數(shù)據(jù)的時候會把數(shù)據(jù)讀到用戶指定的緩沖區(qū),但是如果這個時候讀到的數(shù)歷謹據(jù)量比較少,比參數(shù)中指定的長度要小,read 并不會一直等待下去,而是立刻返回。
read 的原則::是數(shù)據(jù)在不超過指定的長度的時候有多少讀多少,沒有數(shù)據(jù)就會一直等待。
所以一般情況下::我們讀取數(shù)據(jù)都需要采用循環(huán)讀的方式讀取數(shù)據(jù),因為一次read 完畢不能保證讀到我們需要長度的數(shù)據(jù),
read 完一次需要判斷讀到的數(shù)據(jù)長度再決定是否還需要再次讀取。
非阻塞情況下::
在非阻塞的情況下,read 的行為::
、如果發(fā)現(xiàn)沒有數(shù)據(jù)就直接返回,
、如果發(fā)現(xiàn)有數(shù)據(jù)那么也是采用有多少讀多少的進行處理.
所以::read 完一次需要判斷讀到的數(shù)據(jù)長度再決定是否還需要再次讀取。
對于讀而言:: 阻塞和非阻塞的區(qū)別在于沒有數(shù)據(jù)到達的時候是否立刻返回.
recv 中有一個MSG_WAITALL 的參數(shù)::
recv(sockfd, buff, buff_size, MSG_WAITALL),
在正常情況下recv 是會等待直到讀取到buff_size 長度的數(shù)據(jù),但是這里的WAITALL 也只是盡量讀全,在有中斷的情況下recv 還是可能會被打斷,造成沒有讀完指定的buff_size的長度。
所以即使是采用recv + WAITALL 參數(shù)還是要考慮是否需要循環(huán)讀取的問題,在實驗中對于多數(shù)情況下recv (使用了MSG_WAITALL)還是可以讀完buff_size,
所以相應的性能會比直接read 進行循環(huán)讀要好一些。
注意:: //使用MSG_WAITALL時,sockfd必須處于阻塞模式下,否則不起作用。
//所以MSG_WAITALL不能和MSG_NONBLOCK同時使用。
要注意的是使用MSG_WAITALL的時候,sockfd 必須是處于阻塞模式下,否則WAITALL不能起作用。
寫
阻塞與非阻塞寫的區(qū)別: //
寫(send/write/msgsnd)::
寫的本質(zhì)也不是進行發(fā)送操作,而是把用戶態(tài)的數(shù)據(jù)copy 到系統(tǒng)底層去,然后再由系統(tǒng)進行發(fā)送操作,send,write返回成功,只表示數(shù)據(jù)已經(jīng)copy 到底層緩沖,而不表示數(shù)據(jù)已經(jīng)發(fā)出,更不能表示對方端口已經(jīng)接收到數(shù)據(jù).
對于write(或者send)而言,
阻塞情況下:: //阻塞情況下,write會將數(shù)據(jù)發(fā)送完。(不過可能被中斷)
在阻塞的情況下,是會一直等待,直到write 完,全部的數(shù)據(jù)再返回.這點行為上與讀操作有所不同。
原因::
讀,究其原因主要是讀數(shù)據(jù)的時候我們并不知道對端到底有沒有數(shù)據(jù),數(shù)據(jù)是在什么時候結束發(fā)送的,如果一直等待就可能會造成死循環(huán),所以并沒有去進行這方面的處理;
寫,而對于write, 由于需要寫的長度是已知的,所以可以一直再寫,直到寫完.不過問題是write 是可能被打斷嗎,造成write 一次只write 一部分數(shù)據(jù), 所以write 的過程還是需要考慮循環(huán)write, 只不過多數(shù)情況下一次write 調(diào)用就可能成功.
非阻塞寫的情況下:: //
非阻塞寫的情況下,是采用可以寫多少就寫多少的策略.與讀不一樣的地方在于,有多少讀多少是由網(wǎng)絡發(fā)送的那一端是否有數(shù)據(jù)傳輸?shù)綖闃藴剩菍τ诳梢詫懚嗌偈怯杀镜氐木W(wǎng)絡堵塞情況為標準的,在網(wǎng)絡阻塞嚴重的時候,
網(wǎng)絡層
沒有足夠的內(nèi)存來進行寫操作,這時候就會出現(xiàn)寫不成功的情況,阻塞情況下會盡可能(有可能被中斷)等待到數(shù)據(jù)全部發(fā)送完畢, 對于非阻塞的情況就是一次寫多少算多少,沒有中斷的情況下也還是會出現(xiàn)write 到一部分的情況.
linux connect 阻塞的介紹就聊到這里吧,感謝你花時間閱讀本站內(nèi)容,更多關于linux connect 阻塞,Linux環(huán)境下connect阻塞解決方案,linux網(wǎng)絡編程,為什么要將文件描述符設置成非阻塞模式的信息別忘了在本站進行查找喔。
成都創(chuàng)新互聯(lián)科技有限公司,經(jīng)過多年的不懈努力,公司現(xiàn)已經(jīng)成為一家專業(yè)從事IT產(chǎn)品開發(fā)和營銷公司。廣泛應用于計算機網(wǎng)絡、設計、SEO優(yōu)化、關鍵詞排名等多種行業(yè)!
文章題目:Linux環(huán)境下connect阻塞解決方案(linuxconnect阻塞)
網(wǎng)頁網(wǎng)址:http://www.dlmjj.cn/article/djidhsd.html


咨詢
建站咨詢
