在同一台机器上通过UDP套接字发送数据可靠吗？
如果我使用 UDP 套接字进行进程间通信，我是否可以期望其他进程以相同的顺序接收所有发送数据？
我知道一般来说 UDP 并非如此。
If i use UDP sockets for interprocess communication, can i expect that all send data is received by the other process in the same order?
I know this is not true for UDP in general.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
不，我以前也被这个咬过。您可能想知道它怎么会失败，但您会遇到待处理数据包缓冲区填满的问题，从而导致数据包被丢弃。网络子系统如何丢弃数据包取决于实现，并且没有在任何地方指定。
No. I have been bitten by this before. You may wonder how it can possibly fail, but you'll run into issues of buffers of pending packets filling up, and consequently packets will be dropped. How the network subsystem drops packets is implementation-dependent and not specified anywhere.
简而言之，不。您不应该对 UDP 套接字上接收的数据的顺序做出任何假设，即使是通过本地主机也是如此。它可能有效，可能无效，并且不能保证有效。
In short, no. You shouldn't be making any assumptions about the order of data received on a UDP socket, even over localhost. It might work, it might not, and it's not guaranteed to.
不，即使使用本地套接字，也没有这样的保证。如果您想要一个 IPC 机制来保证按顺序传递，您可以考虑使用带有
popen()的全双工管道。这将打开一个通往子进程的管道，该管道可以任意读取或写入。它将保证按顺序交付，并且可以与同步或异步 I/O（select()或poll()）一起使用，具体取决于您想要如何构建应用。在 unix 上还有其他选项，例如 unix 域套接字或 System V 消息队列（其中一些可能更快），但从管道读取/写入非常简单并且有效。另一个好处是可以很容易地测试您的服务器进程，因为它只是从 Stdio 读取和写入。
在 Windows 上，您可以查看命名管道，它的工作方式与 UNIX 的同名管道有些不同，但正是用于这种进程间通信。
No, there is no such guarantee, even with local sockets. If you want an IPC mechanism that guraantees in-order delivery you might look into using full-duplex pipes with
popen(). This opens a pipe to the child process that either can read or write arbitrarily. It will guarantee in-order delivery and can be used with synchronous or asynchronous I/O (select()orpoll()), depending on how you want to build the application.On unix there are other options such as unix domain sockets or System V message queues (some of which may be faster) but reading/writing from a pipe is dead simple and works. As a bonus it's easy to test your server process because it is just reading and writing from Stdio.
On windows you could look into Named Pipes, which work somewhat differently from their unix namesake but are used for precisely this sort of interprocess communication.
Loopback UDP 在许多平台上都非常不可靠，您可以轻松看到 50% 以上的数据丢失。人们给出了各种借口，大意是有更好的运输机制可供使用。
现在有许多中间件堆栈可以使 IPC 更易于使用和跨平台。看看 ZeroMQ 或 29 West 的 LBM 使用相同的 API 进行进程内、进程间 (IPC) 和网络通信。
Loopback UDP is incredibly unreliable on many platforms, you can easily see 50%+ data loss. Various excuses have been given to the effect that there are far better transport mechanisms to use.
There are many middleware stacks available these days to make IPC easier to use and cross platform. Have a look at something like ZeroMQ or 29 West's LBM which use the same API for intra-process, inter-process (IPC), and network communications.
套接字接口可能不会对数据的发起者进行流控制，因此如果您具有更高级别的流控制，您可能会看到可靠的传输，但内存紧缩仍然有可能导致数据报丢失。
如果没有流量控制限制数据报的内核内存分配，我想它会像网络 UDP 一样不可靠。
The socket interface will probably not flow control the originator of the data, so you will probably see reliable transmission if you have higher level flow control but there is always the possibility that a memory crunch could still cause a dropped datagram.
Without flow control limiting kernel memory allocation for datagrams I imagine it will be just as unreliable as network UDP.