UDP是一个完全可行的协议。对于正确的工作来说,正确的工具就是同样的老案例!
如果你有一个等待UDP数据报的程序,然后在返回等待另一个程序之前处理它们,那么你的处理时间总是比数据报的最坏情况到达率要快。如果不是,则UDP套接字接收队列将开始填充。
这可以容忍短爆发。队列完成它应该做的事 - 排队数据报,直到你准备好了。但如果平均到达率经常导致队列积压,现在是重新设计程序的时候了。这里有两个主要的选择:通过狡猾的编程技术减少处理时间,和/或多线程你的程序。也可以使用跨多个程序实例的负载平衡。
如上所述,在Linux上,您可以检查proc文件系统以获取有关UDP的最新状态。例如,如果我cat
的/proc/net/udp
节点,我得到的是这样的:
$ cat /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
40: 00000000:0202 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 3466 2 ffff88013abc8340 0
67: 00000000:231D 00000000:0000 07 00000000:0001E4C8 00:00000000 00000000 1006 0 16940862 2 ffff88013abc9040 2237
122: 00000000:30D4 00000000:0000 07 00000000:00000000 00:00000000 00000000 1006 0 912865 2 ffff88013abc8d00 0
从这个,我可以看到,通过用户ID 1006所拥有的插座,正在侦听端口0x231D(8989)和接收队列大约在128KB。由于128KB是我系统上的最大容量,这告诉我我的程序在跟上到达的数据报时非常脆弱。到目前为止,已经有2237个丢包,这意味着UDP层不能将更多的数据报放入套接字队列,并且必须丢弃它们。
您可以随时观看您的节目的行为,例如,使用:
watch -d 'cat /proc/net/udp|grep 00000000:231D'
还要注意netstat命令做的是同一件事:netstat -c --udp -an
我为我的威尼程序的解决方案,将是多线程。
干杯!
感谢rx_queue,剩下的 - 请参阅更新) – 2010-02-19 05:35:49
@Juliano谁说他可以选择协议来使用?也许他正在实施基于udp的协议来为现有客户提供服务。 – steffen 2013-12-11 10:59:08
海报希望了解有关监视UDP统计信息的信息,而不是关于使用哪种协议的意见。通过首先确定层损失发生的位置,然后可以进行修复。 – RickS 2015-05-20 23:10:46