NIO中的非阻塞TCP / IP SocketChannel
和Selector
帮助我处理许多线程数量少的TCP / IP连接。但UDP DatagramChannels
怎么样? (我必须承认我对UDP不太熟悉。)
即使DatagramChannel
未在阻止模式下运行,UDP发送操作似乎也不会阻止。是否存在DatagramSocket.send(DatagramPacket)
由于拥塞或类似情况而阻塞的情况?我真的很好奇是否存在这样的情况以及生产环境中可能出现的情况。
如果DatagramSocket.send(DatagramPacket)
实际上没有阻止,我不打算使用连接的DatagramSocket
并仅绑定到一个端口,那么使用非阻塞模式{{1}是没有优势的}和DatagramChannel
?
答案 0 :(得分:15)
我使用Java的DatagramSockets,Channels等已经有一段时间了,但我仍然可以给你一些帮助。
UDP协议不像TCP那样建立连接。相反,它只是发送数据并忘记它。如果确保数据真正到达那里很重要,那就是客户的责任。因此,即使您处于阻塞模式,您的发送操作也只会在刷新缓冲区时阻塞。由于UDP对网络一无所知,因此它会尽早将其写出来,而无需检查网络速度,或者它是否实际到达了预期的位置。因此,对您而言,似乎该频道实际上已准备好进行更多发送。
答案 1 :(得分:8)
UDP不会阻塞(它只会在将数据传输到操作系统时阻塞) 这意味着如果在任何时候下一跳/交换机/机器无法缓冲UDP数据包,它就会丢弃它。在某些情况下,这可能是理想的行为。但这是你需要注意的事情。
UDP也不保证
然而,UDP确实支持多播,因此可以将相同的数据包传递到一个或多个主机。发件人不知道是否有人收到了数据包。
关于UDP的一个棘手的问题是它在大多数情况下是有效的,但有时会以非常难以重现的方式严重失败。出于这个原因,即使您进行了一些测试,它也不应该具有可靠性,并且它似乎有效。
答案 2 :(得分:0)
非阻塞UDP主要用于接收方。 数据包发送只能因本地情况而延迟:本地流量整形工具,如“游戏网卡”,优先考虑其他流量来源的游戏流量,或过载的网卡(不太可能发生)可能会延迟数据包的发送。一旦退出系统。一旦数据包离开本地接口,它就不再是应用程序的关注点。