当目的地离线时，数据报包去了哪里？
那些数据包就这样消失了吗？或者他们在等待目的地？或者数据包返回然后抛出异常？
在java中，DatagramPacket构造函数中的byte[]缓冲区与长度有什么区别？
DatagramPacket dp = new DatagramPacket(new byte[...], length);
Are those packet simply disappear? or they waits for the destination? Or the packet go back then throws an exception?
And in java, what is the difference between the byte[] buffer with the length, in the DatagramPacket constructor?
DatagramPacket dp = new DatagramPacket(new byte[...], length);
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
来自维基百科：
From Wikipedia:
即使目的地在线，也不能保证 UDP 数据包一定会到达、按发送顺序到达，或者不会被分段。 （我相信小于532字节的数据包不会被分片）三个都有可能；同一数据包存在碎片、无序和不完整的情况。
网络的简单性和稳定性将决定 UDP 数据包传输的稳健程度，但您必须假设它至少在某些时候是不可靠的。你能做的就是尽量减少损失。
由您决定如果数据包丢失该怎么办以及如何检测它。
如果您想要广播、可靠的消息传递，我建议您查看 JMS 主题或队列，例如 ActiveMQ。
Even if the destination is online, there is no guarantee, the UDP packet will arrive, arrive in the order sent, or not be fragmented. (I believe packets smaller than 532 bytes will not be fragmented) It is possible to have all three; fragmented, out of order and incomplete for the same packet.
The simplicity and stability of your network will determine how robust UDP packet delivery is, but you have to assume it is unreliable at least some of the time. All you can do is minimise the loss.
It is up to you to decide what to do if a packet is lost and how to detect it.
If you want broadcast, reliable delivery of messages I suggest you look at JMS Topics or Queues, like ActiveMQ.
如果使用UDP协议，你不能保证你的数据包会被收到。
所以答案是，即使目的地不在线，它也会被发送。
TCP协议，保证客户能够收到数据包。即使他离线，一旦他上线，就会收到该数据包。
If using UDP protocol, you can't guarantee that your packet is going to be received.
So the answer is, it will be sent, even if its destination is not online.
TCP protocol, its guaranteed that costumer will receive the packet. Even if he is offline, once he get's online, that packet will be received.
发生的情况取决于“离线”状态的性质。
如果 UDP 消息到达主机，但应用程序未侦听，则该消息通常会被静默丢弃。它绝对不会排队等待应用程序监听。 （这毫无意义，而且有潜在危险。）
如果 UDP 消息由于主机本身离线而无法到达主机，则该消息将被默默丢弃。 （如果数据包可以到达目标主机的本地网络，那么除了主机本身之外，没有任何东西可以判断主机是否确实收到了数据包。）
如果网络不知道如何将 IP 数据包路由到在 UDP 服务器（以及其他一些场景）中，ICMP“目标无法到达”数据包可能被发送到发送方，并且通常会被报告为 Java 异常。但这并不能得到保证。所以可能的结果是：
UDP 数据包被黑洞，发送者没有得到任何指示，或者
UDP 数据包被黑洞，发送方收到 Java 异常。
如果 UDP 数据包被防火墙阻止，则行为很难预测。 （防火墙经常在对不需要的流量的响应中“撒谎”。）
您期望 UDP 流量排队的唯一情况是当网络正在工作、主机正在工作并且应用程序正在侦听时。如果应用程序接受数据包的速度很慢，则可能会出现有限的排队情况；即在数据报套接字上连续调用
receive之间的时间过长。但即使在那里，排队/缓冲也受到严格限制，超出范围消息将被丢弃。What happens depends on the nature of the "offline" status.
If the UDP message reaches the host, but the application is not listening, it will typically be silently discarded. It definitely won't be queued waiting for the application to listen. (That would be pointless, and potentially dangerous.)
If the UDP message cannot get to the host because the host itself is offline, the message will be silently discarded. (If the packets can reach the destination host's local network, then there is nothing apart from the host itself that can tell if the host actually received the packets.)
If the network doesn't know how to route the IP packets to the UDP server (and a few other scenarios), an ICMP "Destination Unreachable" packet may be sent to the sender, and that typically gets reported as a Java exception. However this is not guaranteed. So the possible outcomes are:
the UDP packet is black-holed and the sender gets no indication, or
the UDP packet is black-holed and the sender gets a Java exception.
If the UDP packet is blocked by a firewall, then the behaviour is hard to predict. (Firewalls often "lie" in their responses to unwanted traffic.)
The only situation where you would expect there to be queuing of UDP traffic is when the network is working, the host is working and the application is listening. Limited queuing is then possible if the application is slow in accepting the packets; i.e. it takes too long between successive calls to
receiveon the datagram socket. But even there, the queueing / buffering is strictly limited, and beyond that the messages will be dropped.