InputStream緩衝區數據

我的程序使用SSL ServerSocket來等待傳入連接和接收數據。客戶端連接到服務器，並向Socket的OutputStream寫入一個10字節塊的序列。在每個10字節塊後OutputStream是flush() ed，因爲塊應該儘快到達服務器（注意：此處使用WIFI）。InputStream緩衝區數據

然後這些塊被服務器讀取。使用OpenJDK 7在Ubuntu Linux上運行服務器可以正常工作。

但在Windows上使用太陽Java 7運行服務器導致以下問題：
我測量了接收到的塊之間的服務器上的時間。我注意到儘管客戶端在寫入數據塊後使用flush()，但數據有時候太晚被服務器接收/讀取。

例如：
接收第一個塊需要265ms。接下來的15個塊有0ms到16ms的延遲。
之後，下一個塊在172ms後到達。但是下面的10個塊再次只需要0ms到16ms。

所以看起來好像有些字節是由InputStream接收和緩衝的。然後在某個時間點（例如，超過150ms之後），InputStream的read-方法返回一些數據。之後，read-方法立即返回一些字節的數據（0ms到16ms）。然後它又需要一些時間。
我知道一個InputStream使用緩衝區和read - 方法塊，直到一個新的字節可用。但似乎read-方法不會盡可能快地返回數據。

客戶端始終是Android應用程序。但是由於在Linux上運行的服務器不會發生問題（總是在塊之間平均20毫秒），所以問題必須是服務器或JRE。

關於如何解決問題的任何想法？我真的需要客戶端發送的塊的「流動」傳輸，因爲Android應用上的交互應該以接近實時的動畫形式顯示在服務器上。但延遲265毫秒這些動畫卡住了。

來源

2012-10-05 Biggie

的InputStream緩衝區數據

不，它不需要。除非使用BufferedInputStream，否則沒有任何InputStream緩衝。您的發送的正由內核中的TCP Nagle算法合併。在發件人處調用Socket.setTcpNoDelay（true）。

您應該知道，通過SSL發送10字節的塊是非常低效的。 SSL本身的記錄開銷約爲44字節，而TCP又是20字節，所以你的數據爆炸將近4倍。如果可能的話，請使用明文。

來源

2012-10-05 22:54:01 EJP

好吧，我的意思是，數據被緩衝「某處」...不一定在InputStream中。 :-)在服務器和客戶端上使用'Socket.setTcpNoDelay（true）'解決了這個問題。現在兩塊之間的時間在大多數情況下只能達到16ms。謝謝 – Biggie

爲什麼你認爲這個問題是InputStream讀取方法？你是否設置了包嗅探器，實際上是手錶的網絡流量？ Java沒有做緩衝，網絡堆棧是。通過調整某些套接字設置，您可能會或可能無法影響該功能。

來源

2012-10-05 15:27:05 jtahlborn

InputStream緩衝區數據

回答

相關問題