Why should I use, or not use, MSG_CONFIRM?

Question

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.

The description says:

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.

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?

Answer 1

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.

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.

Answer 2

The reason to not send it is in case the mac address for the IP changes over time. If you're constantly telling your system not to check, it will continue to send to the same MAC even if the IP address isn't there anymore.

It seems the case for sending it requires a very special situation where you can guarantee things about the recipient of your messages. The overhead of a periodic ARP request is very low, so the benefits are extremely limited.