通過環回接口調度UDP數據包的延遲？

我打算編寫一個程序來偵聽UDP端口，然後將數據分派到多個服務器實例。服務器軟件的代碼已經構造爲偵聽端口本身，而不是從本地運行的另一個程序接收數據。所以我的想法基本上是通過回送接口創建從前端程序到服務器實例的第二個UDP流。應用程序對延遲非常關鍵，即開銷不應超過1毫秒。我想知道那麼這是否是最好的方法：我擔心這個數據包會再次被內核調度（Linux，在我的情況下）。如果我是對的，這個延遲是否會顯着？如果是這樣，是唯一的解決方案來重寫前端和服務器應用程序之間的新型進程間通信？通過環回接口調度UDP數據包的延遲？

來源

2012-03-26 Lorenzo Pistone

你不能只說「延遲是關鍵」。 *多少*延遲太多？你將不得不嘗試。我不知道你的意思是「UDP流」。 UDP不是流，它是一系列數據包。 – EJP 2012-03-26 22:27:41

通過關鍵我的意思是我不想有超過1毫秒的響應性的缺點。而關於UDP流，好吧，選擇你喜歡的同義詞：談話，轉換，數據包交換。 – 2012-03-26 22:39:16

調度不是真正的問題。如果進程或線程正在等待select()或recvmsg()，它應該幾乎立即被傳入的數據報喚醒。（發送者在調用sendmsg()時放棄其CPU片，內核通過回送傳遞消息，然後接收者將高於調度器中的發送者。）

通過回送接口的延遲將是亞毫秒，假設接收器已準備好接收。

大部分的延遲時間都來自每個接收器在從套接字讀取數據包之間進行的操作。例如，如果接收器在收據之間需要0.5毫秒的CPU時間處理，那麼您的延遲時間將大約爲0.5毫秒。但是如果你每CPU核心運行3個這樣的接收器，那麼你的延遲不能少於1.5毫秒。

來源

2012-03-27 01:49:59

通過環回接口調度UDP數據包的延遲？

回答

相關問題