ServerSocket.accept（）是一種阻塞方法 - 多個偵聽器加速？

在應用程序中， ServerSocket實例正在接受連接並將其傳遞給線程。該端口上的連接全部都是線程化的 - 一個線程用於一個連接。套接字監聽器看起來是這樣的：ServerSocket.accept（）是一種阻塞方法 - 多個偵聽器加速？

serverSocket = new ServerSocket(port); 
for (;;) { // keep listening 
    Socket socket = serverSocket.accept(); 
    Thread t = new LRcvr(socket); 
    t.start(); 
}

什麼，我想知道是，是否有更多的工作要做，以加快這在插座上的高流量情況。

我特別關心ServerSocket.accept()。在多個連接請求中，比如req-1 & req-2, req-1在req-2之前到達端口。但是，插座& req-1 由於某種原因不能及時建立，並且這塊 req-2正在「聽到」其請求並因此在端口上連接。這整個事情是因爲方法ServerSocket.accept()是一個阻塞的。

必須有一個聰明的方法來解決這個問題。它是什麼？

創建多個插座偵聽器聽到&接受連接請求想到，但會工作 - 如何？我應該多線程的套接字監聽器？那麼我應該擔心什麼？

注意：我們只能操作一個端口 - 多個套接字不是這裏的一個選項。

TIA

來源

2014-07-03 Roam

在你的例子中，req-1不會阻止req-2被聽到。

ServerSocket.accept()僅阻止應用程序級處理新連接，並且在建立連接時觸發它。

如果與req-1的連接尚未建立，它還沒有暴露給應用程序級別。當req-2連接時，accept()將愉快地解鎖。

（產卵場爲每一個連接一個新線程可能是一個問題，但，如果你接受10000個連接嗎？我不知道現代JVM和/或內核可以有效地處理線程的這一數額。）

來源

2014-07-03 23:07:34 Inspired

你是什麼意思「新連接的應用程序級處理」 - 你能更具體嗎 – Roam

所有TCP連接的低級內容通常由OS（內核）處理。 OS監聽網絡，識別建立TCP連接的請求，執行所有這些三方握手等等。你在例子中描述的內容可能發生在操作系統級別，但操作系統以非阻塞方式處理連接，不問題在那裏。當你調用accept（）時，你基本上要求操作系統給你第一個準備好使用的連接，如果沒有準備好的連接，這個調用會阻塞你的應用程序。通話不會阻止操作系統。我正是這個意思。 – Inspired

在多個連接請求中，比如req-1 & req-2，req-1在req-2之前到達端口。但是，插座& req-1之間的連接由於某種原因而不能及時建立起來

某些原因如？定義。在任何情況下，如果連接沒有建立，它永遠不會到達TCP backlog隊列，更不用說accept（）方法了。

這個塊REQ-2被「聽」其請求

不，它不需要。

因此在港口連接。

不，它不。連接請求由TCP完全處理，並置於積壓隊列中，而不管accept（）是或不在做什麼。

這整個事情是因爲ServerSocket.accept（）方法是阻塞的。

不，它不是。首先「這整個事情」甚至不存在，其次，accept（）阻塞的事實對它沒有任何影響。

必須有一個聰明的方法來解決這個問題。

這裏沒有什麼可以「繞過」。你的問題是虛構的。

來源

2014-07-04 00:04:25 EJP

ServerSocket.accept（）是一種阻塞方法 - 多個偵聽器加速？

回答

相關問題