socket程式設計中應用recv判斷連線已斷開
在網路程式設計中,經常會檢測網路的連線情況,進而進行下面的動作。在Linux的socket程式設計中,有一種非常方便的方法,來判斷對方是否斷開了連線,就是使用recv函式。
在APUE 中,對 recv的表述如下,
#include <sys/socket.h>
ssize_t recv(int sockfd, void *buf, size_t nbytes, int flags);
返回值:返回資料的位元組長度;若無可用資料或對等方已經按序結束,返回0;若出錯,返回-1
如果傳送端主動關閉傳輸,或是傳送端主動關閉了連線後,recv最終會返回0.
利用這個特性,可以用 recv返回0來進行傳送方斷開連線的判斷。
/* receive ready*/
if(FD_ISSET(clientfd,&rdset_tmp)){
recbytes = recv(clientfd,buff,RECV_DATA_LEN,0);
if(recbytes>0){
/* recv data handle */
#if debug_printf
printf("recv data %d bytes\n",recbytes);
#endif
if(buff[0]==0x56 && buff[1]==0x88)
send_flag=0x55;
}else if(recbytes==0){
/* the client disconnect 返回0,傳送端已斷開連線*/
#if debug_printf
printf("client%d disconnect\n",clientIndex+1);
#endif
pthread_mutex_lock(&clientsMutex28000[i]);
clients28000[clientIndex].isConn = 0;
pthread_mutex_unlock(&clientsMutex28000[i]);
pthread_mutex_lock(&activeConnMutex28000);
if(activeConn)
activeConn--;
pthread_cond_signal(&connDis28000);
pthread_mutex_unlock(&activeConnMutex28000);
break;
}
}
需要注意的是:此種方法只能判斷髮送端主動斷開連線的行為,對於網路異常等客觀原因出現連線斷開的情況無法判定,可以藉助心跳資料等方式進一步判定。
相關推薦
socket程式設計中應用recv判斷連線已斷開
在網路程式設計中,經常會檢測網路的連線情況,進而進行下面的動作。在Linux的socket程式設計中,有一種非常方便的方法,來判斷對方是否斷開了連線,就是使用recv函式。 在APUE 中,對 recv的表述如下, #include <sys/sock
socket程式設計中send recv阻塞和非阻塞詳解
int send( SOCKET s, const char FAR *buf, int len, int flags ); 不論是客戶還是伺服器應用程式都用send函式來向TCP連線的另一端傳送資料。客戶程式一般用send函式向伺服器傳送請求,而伺服器則通常用send函
Linux網路程式設計中服務端判斷客戶端斷開連線。
</pre> 專案使用了select模型,所以這裡只貼出此模型下的客戶端連線斷開判斷:<p></p><p>主要是select返回後,正常recv,如果recv的返回值小於0則表示客戶端連線已斷開。</p><
Java Socket程式設計中處理長連線的方法
因為實習可能要用Java,所以學習了一下Java,正好計算機網路實驗要寫一個Web伺服器,可以用來練練手。 實現Web伺服器時,最基本的流程就是當有客戶端連線伺服器時,把連線交給一個執行緒,由這個執行緒來處理這個連線。處理的流程也很簡單,就是讀取一個請求,然後
WINDOWS SOCKET程式設計中accept出來的新連線是阻塞還是非阻塞
實踐證明 SOCKET hNewSock=accept(hListenSock) 當hListenSock為阻塞模型時,hNewSock則為阻塞模型 否則 當hListenSock為非阻塞模型時,hNewSock則為非阻塞
C++程式設計-socket程式設計中為何要使用迴圈來呼叫阻塞式recv
你是否奇怪阻塞式接收recv這樣的函式為什麼要用一個for迴圈才能收全所有的內容?至少其中一種可能性是因為UNIX的訊號處理機制。 在我的程式設計理念中,UNIX下的訊號是一個徒增麻煩的東西,這也許是非控制檯的Windows程式中沒有訊號的原因。
socket 程式設計中。 服務端用到多執行緒
客戶端連線服務端之後, 服務端會生成與客戶端交換資訊的socket。 在服務端實現多執行緒: 為每個連線建立一個執行緒進行資訊交換。 import threading from socket import * from time import ctime HOST='127.0.0
TCP與UDP在socket程式設計中的區別
一、TCP與UDP的區別 基於連線與無連線 對系統資源的要求(TCP較多,UDP少) UDP程式結構較簡單 流模式與資料報模式 TCP保證資料正確性,UDP可能丟包 TCP保證資料順序,UDP不保證 部分滿足以下幾點要求時,應該採用UDP 面向資料報方式 網路資料大多為短訊息
關於Socket程式設計中的inet_ntop、inet_pton和inet_ntoa、inet_addr
VS2013中除錯Socket程式碼時,遇到了點小問題: 問題程式碼為: inet_ntoa(addrClient.sin_addr); 生成錯誤訊息為: error C4996: 'inet_ntoa': Use inet_ntop() or InetNtop() instead or de
socket程式設計中父子程序、兄弟程序的埠問題
通過實驗顯示,還是埠A。為什麼?埠複用技術!那麼,實驗是怎麼做的呢?其實很簡單,server端啟動,在fork出子程序時保證每個子程序的連線保持(可以通過sleep讓其休息一會),此時,通過 “netstat -pan | grep A” 就可以看到有關埠A的一些資訊,可以發現有子程序通過A與對應的clien
socket程式設計中遇到的一些小問題
1、htonl(u long ip),將ip地址轉換為網路位元組形式; 2、inet_addr("192.168.1.1"),將字串轉換為u long型ip,注意,此時已經為網路位元組,不需要再用htonl進行轉換。
UDP socket程式設計中使用connect
int recv(int s, void *buf, size_t len, int flags); int recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen); 從他
C++ TCP socket程式設計中的小陷阱(服務端accept 不阻塞 和 客戶端connect 重連失敗)
在編寫一個使用C++ socket實現的TCP服務端與客戶端小軟體時接連碰上2個小陷阱, 終歸是實踐不足,基本功不紮實。 第1個問題: 服務端的accept函式沒有阻塞 程式執行到accept這裡時直接就跳了過去,根本沒停下來。 懷疑過socket
SOCKET程式設計中,select()函式的作用
參考1: 它允許程序指示核心阻塞在等待多個事件中的任一個發生,並僅在一個或多個事件發生或經過某指定的時間後才喚醒程序。#include <sys/select.h>#include <sys/time.h>#include <sys/typ
Socket程式設計中select()的妙用
【 原文由 cpu 所發表 】 用過 WinSock API 網友們知道:WinSock 程式設計中有一很方便的地方便是其 息驅動機制,不管是底層 API 的 WSAAsyncSelect() 還是 MFC 的非同步Socket類: CAsyncSocket,都提供了諸如 FD_ACCEPT、FD_
關於SOCKET程式設計中“燙燙燙...”的問題
近幾日一直在學習SOCKET通訊,關於網路程式設計這塊兒一是空白。學習的過程中在網上找了一段原始碼,據說是孫鑫老師教程裡的。新建一個工程,執行原始碼一切似乎很正常。於是自己改了一下程式,再次執行發現客戶端第一次接收到資料時一直顯示”燙燙燙“的亂碼。經過網上查詢資
關於socket程式設計中的INADDR_ANY
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 4
談談網路程式設計中應用層(基於TCP/UDP)的協議設計
對於初涉網路程式設計的開發人員來說,在通訊協議的設計上一般會有所困惑。一般的網路程式設計書籍上也較少涉及這方面的內容。估計是覺得太簡單了。這塊確實是不難,但如果不瞭解,又很容易出簍子或者繞彎路。下面我就來談談基於TCP/UDP的協議設計。 1、基於TCP的協議
socket程式設計中的WSAStartup函式
WSAStartup int WSAStartup( WORD wVersionRequested, LPWSADATA lpWSAData); 簡介 WSAStartup,即WSA(Windows Sockets Asynchronous,Windows
Socket程式設計中的inputstream阻塞問題
今天在使用socket程式設計時,想把從客戶端獲取的資料轉換成String物件。使用了程式碼 // 將流物件轉成String物件 String data = org.apache.commons.io.IOUtils.toString(socket.getInputStr