linux - 连接的 UDP 套接字的意外行为

Question

根据 connect() 的联机帮助页，

If the socket sockfd is of type SOCK_DGRAM, then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received.

我有程序 A 在其地址为 127.0.0.1 和端口 1212 的套接字上调用 connect 和程序 B 在其地址为 IN_ADDRANY 和端口 1212 的套接字上调用 bind .

当程序 A 使用 send 发送数据包时，程序 B 接收数据包并使用 recvfrom 指示源地址实际上是 127.0.0.1。

当程序 B 在 bind 之后在地址为 127.0.0.1 和端口 1212 的套接字上调用 connect 时，问题就来了。当程序 A 发送数据包时，程序 B 将不再接收数据包。

这是预期的行为吗？

Answer 1

Is this expected behavior?

我希望如此(哈哈)——我认为问题是程序 B 的 connect() 调用告诉 B 的 UDP 套接字它应该只接受来自 127.0.0.1:1212 的传入 UDP 数据包-- 但程序 A 的数据包实际上来自 127.0.0.1:xxxxx，其中 xxxxx 是网络堆栈隐式绑定(bind)程序 A 的 UDP 套接字的任意可用端口，因为程序 A 从未调用过 bind()显式地(并且 A 的 UDP 套接字需要在 send() 工作之前绑定(bind)到端口，否则操作系统不知道如何填写 UDP 数据包 header 中的源端口字段)

如果是这种情况，那么您的选择是在调用 connect() 之前让程序 A 显式 bind() 将其套接字连接到不同的知名端口，并且send()，或者让程序 B 在调用 connect() 之前以某种方式动态地找出 A 从哪个端口发送，以便 B 可以将适当的端口号传递给连接()。

或者我最喜欢的选择，就是完全避免将 connect() 与 UDP 套接字结合使用，而只使用 sendto() 和 recvfrom( ) 代替。我发现这让我可以更好地控制 UDP 发送/接收行为，从而减少麻烦。