为什么我应该使用或不使用 MSG_CONFIRM? [英] Why should I use, or not use, MSG_CONFIRM?

问题描述

我熟悉 BSD 套接字，在翻阅 sendto 的手册页时，我碰到了 MSG_CONFIRM 标志，这对我来说很神秘.

I am acquainting with BSD sockets, and flicking through the man page of sendto, I bumped into MSG_CONFIRM flag, which is quite mysterious to me at the moment.

描述说:

告诉链路层发生了前向进展:你得到了一个对方回复成功.如果链路层没有得到这将定期重新探测邻居(例如，通过单播 ARP).仅对 SOCK_DGRAM 和 SOCK_RAW 套接字有效，目前仅针对 IPv4 和 IPv6 实施.

Tell the link layer that forward progress happened: you got a successful reply from the other side. If the link layer doesn't get this it will regularly reprobe the neighbor (e.g., via a unicast ARP). Only valid on SOCK_DGRAM and SOCK_RAW sockets and currently implemented only for IPv4 and IPv6.

快速浏览arp 的手册页后，我了解到标记某些MSG_CONFIRM 会阻止考虑远程机器的ARP 映射MAC 地址↔ IP 地址陈旧.

After a quick look at the man page of arp, I understand that flagging something MSG_CONFIRM prevents the ARP mapping MAC address ↔ IP address of the remote machine from being considered stale.

现在我很困惑，因为我看不出有什么理由我不应该不把它放进去，因此，他们为什么不直接在图书馆里强制执行.为什么应用层要处理链路层下面发生的任何事情.

Now I am puzzled because I can’t see any reason why I should not put it, and therefore, why didn’t they enforce that directly in the library. Why is the application layer expected to deal with anything that happens down there at the link layer.

所以我错过了什么吗?我应该什么时候设置，或者什么时候不设置?

So did I miss anything? when should I set it, or not set it?

推荐答案

如果您发送的数据报是对刚从同一个对等方收到的数据报的直接响应，您应该只设置该标志.

You should only set the flag if the datagram you're sending is a direct response to a datagram you just received from the same peer.

如果您要发送初始请求，或发送数据报以响应某些其他事件(例如用户输入或超时)，那么您应该不要设置 MSG_CONFIRM代码>标志.

If you're sending an initial request, or sending a datagram in response to some other event (like user input, or a timeout) then you should not set the MSG_CONFIRM flag.

这篇关于为什么我应该使用或不使用 MSG_CONFIRM?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！