針對高負載網絡應用程序的最有效的winsock設計

Question

我知道這是一個普遍問題，但我需要關於TCP服務器/客戶端應用程序的推薦。

服務器一次只能處理一個連接。 服務器向連接的客戶端發送實時圖像（一幀約爲50K和20幀/秒）。

實際上，在服務器和客戶端應用程序連接的啓動建立時，理論上應該永久保持這種連接。

我的觀點是，由於服務器發送的實時圖像，延遲必須最小，所以什麼是寫這樣一個（簡單）的TCP服務器和客戶端的最佳實踐，以及如何序列化/反序列化的圖像，使「minumum延遲「目標是否實現？

由於提前，

問候

Answer 1

一種方式是發送使用UDP，而不是TCP數據。

如果這樣做，有些UDP數據包可能會丟失（被網絡丟棄），因此您的代碼需要一種方法（例如數據包頭中的序列號）來檢測丟失的數據包。

如果TCP數據包丟失，那麼TCP將重新發送它，這會導致延遲。對於您的應用程序來說，有可能丟失數據包時，您可能只想在沒有丟失數據包的情況下執行操作，不重傳數據包，不顯示此視頻幀（或僅顯示部分幀），然後繼續顯示下一個幀。

這取決於應用：

• 你流式罐裝/預錄/非實時視頻，在這裏要接收/顯示每幀即使他們中的一些會導致延遲？

• 您是否正在流式直播視頻中，您想近乎實時地顯示當前幀（即使先前的一些幀丟失了，您不想在重新傳輸時延遲）？

---

在winsock的架構而言，TransmitFile或TransmitPackets API是非常有效的：他們是在內核中執行的，而不是造成你的用戶模式代碼和O/S內核模式代碼之間的往返，因爲每個緩衝區都被傳輸。

---

「minumum延遲」目標實現

你可能想一些延遲，以避免抖動：最好是有一個小（例如150毫秒）的固定延遲，比延遲從2到120毫秒不等。見http://www.google.ca/search?hl=en&q=jitter+network

Answer 2

我不是超級權威，但是......

讓我們做一些數學。每個圖像50K（這是字節，對吧？）以每秒20幀的速度大約爲1兆字節每秒。在通信方面，這是每秒10兆比特。這是一個公平的，但非常可行的。確保你有100兆位設備。

這個最快的API是枯燥的舊堵「發送」和「接收」呼叫（* 1）。還有其他的調用Windows IO類型完成端口和什麼的;不要使用他們的這一應用程序（因爲（a）他們是矯枉過正，和（b）他們作出一個應用程序更具可擴展性）

考慮關閉內格爾（該NODELAY選項）。

（* 1）可能。實際上最快的Winsock調用的實際文獻嚴重缺乏。