Socket程式設計中的inputstream阻塞問題
今天在使用socket程式設計時,想把從客戶端獲取的資料轉換成String物件。使用了程式碼
// 將流物件轉成String物件
String data = org.apache.commons.io.IOUtils.toString(socket.getInputStream());
發現執行程式碼時阻塞在這裡了。難道是工具類Bug?追蹤了一下程式碼發現執行到
百度了一下最終發現了問題導致原因:// 執行程式碼input.read(buffer) 發生阻塞 while (EOF != (n = input.read(buffer))) { output.write(buffer, 0, n); count += n; }
read方法執行時如果遇到檔案末尾會返回-1。而socket通訊時,服務端會一直等待客戶端輸入。
所以預設情況下客戶端傳送完了資料之後是不會通知服務端資料傳送完畢。
當我們在編寫客戶端程式碼時,需要手動呼叫socket物件的shutdownOutput()方法。來通知服務端資料傳送完畢。
該方法的目的是告訴服務端客戶端的輸入結束了。但是並不關閉服務端與客戶端的通訊連線。
相關推薦
c++ socket程式設計中accept阻塞問題
在用c++編寫socket程式碼時,出現了,accept不阻塞的問題,感覺很是苦惱,一直查詢問題,發現程式碼時沒有問題的。最終發現把 #include <thread> #include <mutex> 遮蔽掉可以解決,當時就
Socket程式設計中的inputstream阻塞問題
今天在使用socket程式設計時,想把從客戶端獲取的資料轉換成String物件。使用了程式碼 // 將流物件轉成String物件 String data = org.apache.commons.io.IOUtils.toString(socket.getInputStr
C++ TCP socket程式設計中的小陷阱(服務端accept 不阻塞 和 客戶端connect 重連失敗)
在編寫一個使用C++ socket實現的TCP服務端與客戶端小軟體時接連碰上2個小陷阱, 終歸是實踐不足,基本功不紮實。 第1個問題: 服務端的accept函式沒有阻塞 程式執行到accept這裡時直接就跳了過去,根本沒停下來。 懷疑過socket
WINDOWS SOCKET程式設計中accept出來的新連線是阻塞還是非阻塞
實踐證明 SOCKET hNewSock=accept(hListenSock) 當hListenSock為阻塞模型時,hNewSock則為阻塞模型 否則 當hListenSock為非阻塞模型時,hNewSock則為非阻塞
C++程式設計-socket程式設計中為何要使用迴圈來呼叫阻塞式recv
你是否奇怪阻塞式接收recv這樣的函式為什麼要用一個for迴圈才能收全所有的內容?至少其中一種可能性是因為UNIX的訊號處理機制。 在我的程式設計理念中,UNIX下的訊號是一個徒增麻煩的東西,這也許是非控制檯的Windows程式中沒有訊號的原因。
socket程式設計中send recv阻塞和非阻塞詳解
int send( SOCKET s, const char FAR *buf, int len, int flags ); 不論是客戶還是伺服器應用程式都用send函式來向TCP連線的另一端傳送資料。客戶程式一般用send函式向伺服器傳送請求,而伺服器則通常用send函
安卓開發SOCKET程式設計中幾種執行緒阻塞產生的原因與解決辦法
在使用socket程式設計中,有幾種情況會使執行緒產生阻塞。 1、解析DNS阻塞 當需要把一個域名解析為IP地址的時候,可用使用以下語句來獲得。使用下面API的時候,如果當前環境沒有網路,或者網路異常,將會使得解析失敗,getByName方法會丟擲異常,但是
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
Java Socket程式設計中處理長連線的方法
因為實習可能要用Java,所以學習了一下Java,正好計算機網路實驗要寫一個Web伺服器,可以用來練練手。 實現Web伺服器時,最基本的流程就是當有客戶端連線伺服器時,把連線交給一個執行緒,由這個執行緒來處理這個連線。處理的流程也很簡單,就是讀取一個請求,然後
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); 從他
socket程式設計中應用recv判斷連線已斷開
在網路程式設計中,經常會檢測網路的連線情況,進而進行下面的動作。在Linux的socket程式設計中,有一種非常方便的方法,來判斷對方是否斷開了連線,就是使用recv函式。 在APUE 中,對 recv的表述如下, #include <sys/sock
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
socket程式設計中的WSAStartup函式
WSAStartup int WSAStartup( WORD wVersionRequested, LPWSADATA lpWSAData); 簡介 WSAStartup,即WSA(Windows Sockets Asynchronous,Windows