如何选择“正确”插座发送数据报响应？
我有一些perl代码，可以通过选择在插座上听，然后在大量处理后发送一些其他例程。
现在的问题是（假设我在$ $ dest中都有同行的地址）： 如何选择用于将响应发送到$ $ dest的“正确”套接字？
我是否应该盲目地使用收到请求的插座，还是应该尝试复制路由逻辑以找到“最佳”套接字，考虑到每个套接字的地址，将其与$ $ $ dest进行比较不知何故？
不幸的是，我几乎没有想法。
我忘记了一个特殊情况（实际上触发了现有代码中的问题）：
可能会通过在可以设置响应之前收到请求的插座来减少侦听插座的数组； 因此，似乎我需要实施第二种选择。
I have some Perl code that listens on an array of sockets via select for a request, and then some other routine sends out a response after significant processing.
Now the question is (assuming I have the peer's address in $dest):
How should I select the "correct" socket to use for sending the response to $dest?
Should I blindly use the socket where the request was received on, or should I try to duplicate routing logic to find the "best" socket, considering the address each socket is bound to, comparing it with $dest somehow?
I have little ideas how to do the latter, unfortunately.
I forgot one special case (that actually triggered the problem in the existing code):
It is possible that the array of listening sockets is reduced by the socket that received the request before the response can be set;
thus it seems I need to implement the second alternative.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该使用相同的插座与给定的对等方进行所有通信。
有时候它无关紧要，但是有时确实如此。
就是说，您可能只有插座。
当您从UDP套接字接收时，您将提供插座起源的地址和端口。 [1] 这允许一个套接字与许多其他插座通信。
例如，
假设服务器S的套接字为0.0.0.0:1111，其IP地址之一为1.1.1.1。
说客户端A的插座为0.0.0.0:2222，并说它使用IP地址2.2.2.2达到1.1.1.1。
说客户端B的插座为0.0.0.0:3333，并说它使用IP地址3.3.3.3达到1.1.1.1。
当服务器调用
recv时，它将返回2.2.2.2：2222或3.3.3.3.3：3333（以“包装”表单），具体取决于A还是B发送消息。这使服务器可以知道谁在与之通信，以及在回复时使用什么地址。在TCP世界中，服务器可能会将每连接数据保存在由客户端套接字键入的哈希（
Accept）键入的哈希中。但是在UDP世界中，类似的服务器可以将每个连接数据保留在由recv返回的字符串键入的哈希中。这说明了为什么始终使用相同的插座发送和接收消息很重要的原因。如果您开始从不同的插座发送，此哈希查找将失败。
在某种情况下，您需要多个插座，这是您想收听一些但不是全部网络接口的时候。例如，您可能需要收听回环适配器（127.0.0.1）和用于与VM（XXXX）通信的虚拟适配器，但不与WiFi适配器（Yyyy）或以太网适配器（Zzzz）
插座can can can can要么收听所有接口（通过绑定到ipaddr_any（0.0.0.0），即默认值），或一个接口。因此，聆听（仅）两个接口需要一个插座绑定到一个接口之一（127.0.0.1），另一个插座绑定到另一个插座（xxxx）。
在这里，至关重要的是使用正确的套接字。从插座绑定到回环适配器的消息无法到达VM，并且从插座绑定到VM的适配器的消息无法达到回环适配器。
You should use the same socket for all communication with a given peer.
There are times where it doesn't matter, but there are times that it does.
That said, you probably should only have socket.
When you receive from a UDP socket, you are give the the address and port from which the socket originated.[1] This allows one socket to communicate with many other sockets.
For example,
Say the server S's socket is 0.0.0.0:1111 and one of its IP addresses is 1.1.1.1.
Say client A's socket is 0.0.0.0:2222 and say it uses IP address 2.2.2.2 to reach 1.1.1.1.
Say client B's socket is 0.0.0.0:3333 and say it uses IP address 3.3.3.3 to reach 1.1.1.1.
When the server calls
recv, it will return either 2.2.2.2:2222 or 3.3.3.3:3333 (in a "packed" form) depending on whether A or B sent the message. This allows the server to know who is communicating with it, and what address to use when replying.In the TCP world, the server might keep per-connection data in a hash keyed by client socket (the socket returned by
accept). But in the UDP world, a similar server could keep per-connection data in a hash keyed by the string returned byrecv.This illustrates one reason why it's important to always use the same socket to send and receive message. If you start sending from different sockets, this hash lookup would fail.
There is one situation in which you'd want multiple sockets, and that's when you want to listen to some but not all network interfaces. For example, you might want to listen to the loopback adapter (127.0.0.1) and the virtual adapter used for communicating with a VM (x.x.x.x), but not to the wifi adapter (y.y.y.y) or the ethernet adapter (z.z.z.z)
A socket can either listen to all interfaces (by being bound to IPADDR_ANY (0.0.0.0), which is the default), or one interface. So listening (only) two interfaces requires having one socket bound to one of the interfaces (127.0.0.1) and another socket bound to the other (x.x.x.x).
Here, it's critical that you use the correct socket. Messages sent from the socket bound to the loopback adapter won't reach the VM, and messages sent from the socket bound to the VM's adapter won't reach the loopback adapter.