這個專案中寫的程式是與遠端進行socket通訊，用到accept來接受遠端的連線請求，一直以來在程式裡對accept用的都是阻塞方式，接收到乙個新的連線請求後，就建立乙個新的執行緒處理與客戶端的通訊任務。今天由於需要實現伺服器端設定客戶端心跳包週期的功能，如果每個執行緒都去查詢資料庫裡心跳包週期有沒有發生改變，實現起來太麻煩，就改用使用主線程去查詢資料庫裡存放的心跳包週期，由於主線程需要不停地去查詢資料庫，這樣accept就不能再用阻塞的方式，上網搜了一下，沒找到什麼方法，突然想到我以前recev資料報也是用的阻塞方式，後來用select改為了非阻塞方式，accept能不能也用select實現非阻塞方式呢？自己試著按照recev的非阻塞方式改了一下程式，accept成功實現了非阻塞接收連線請求方式。
int maxfdp=null;
struct fd_set fds;
struct timeval timeout=;
fd_zero(&fds);
fd_set(sock_sev,&fds);
if (select(maxfdp,&fds,null,null,&timeout))
{
cout<<"new connection"<
關於accept非阻塞
最近在做socket程式設計，wifi測試時發現距離遠了之後，拿近了後，熱點會再次連上，但程式裡的socket不會重連，後來發現問題的根源。如下 當乙個已完成的連線準備好被accept的時候,select會把監聽socket標記為可讀 因此,如果用select等待外來的連線時,應該不需要把監聽soc...
TCP非阻塞accept和非阻塞connect
非阻塞accept 當乙個已完成的連線準備好被accept的時候，select會把監聽socket標記為可讀。因此，如果用select等待外來的連線時，應該不需要把監聽socket設定為非阻塞模式，因為如果select告訴我們連線已經就緒，accept就不應該被阻塞。不過這樣做的時候有乙個bug 當...
將伺服器select模型設定為非阻塞，處理更多業務
如果除了相應客戶端的訊息以外，還要主動的去給客戶端推送一些訊息這樣就有些不方便 server 設定select為阻塞狀態的時候，那麼絕大部分的時間都用在等待客戶端連線上面 如果是做乙個純應答型的網路服務程式那麼這樣就可以足夠的使用 如果除了相應客戶端的訊息以外，還要主動的去給客戶端推送一些訊息這樣就...