通过环回接口调度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数据包的延迟？

回答

相关问题