Tcpclient/Tcplistner類比套接字類更快

我的應用程序是用.net編寫的，並運行在Windows服務器上。它通過TCP/IP與遠程服務器連接並繼續監聽。它只在連接開始時發送一條消息，這是一條登錄消息，之後它不會發送任何消息，而只是從服務器偵聽。它的流套接字和數據包保持頻繁發生，大約6000個大小不等的數據包從60字節到200字節不等。到目前爲止，我使用套接字類並連接到遠程服務器。發送登錄請求後，我開始在連續的基礎上接收流。爲了接收我使用BeginReceive的流，socketflags沒有。並且在每次開始接受之後，它都會重複這個任務。是否有任何其他方式以更快的速度接收流？我的應用程序是實時的，非常非常關鍵。即使1微秒也很重要。任何人都可以建議。Tcpclient/Tcplistner類比套接字類更快

來源

2012-01-12 Manish Garg

這將有助於顯示更多的代碼;你的接收循環是什麼樣的？ – bobbymcr 2012-01-12 07:34:45

除非服務器程序位於同一臺計算機上或本地超高速網絡上，否則網絡延遲會使分辨率毫秒級無用。 – 2012-01-12 07:47:00

TcpClient僅僅是在 a Socket和NetworkStream之上的包裝。它不會以更快的速度運行 - 它只是一個不同的（更方便的）API。另外，Joachim指出 - 這不太可能是一個真正的瓶頸。

一些想法，你可以嘗試：

如果使用NetworkStream API，檢查DataAvailable，這表明如果有數據緩存;如果有，那就試試處理同步（通過一些Read），直到DataAvailable是假的，在這一點切換到異步 *（BeginRead）

單獨的緩存信息的步驟VS處理的消息 - 你的電腦最有可能具有多個核心，並且單獨的讀取循環/處理隊列可以增加吞吐量;你也可以考慮並行處理線程，但是這是比較複雜的

當與遠程服務器處理，「即使1個微秒問題」是根本不可行的。在那個級別上，你也希望在垃圾收集方面瘋狂工作，或許看看struct的使用情況（通過ref），這與使用class非常不同，並且不能通過平面交換進行更改。和對象池等非常棘手。

來源

2012-01-12 07:56:24

Tcpclient/Tcplistner類比套接字類更快

回答

相關問題