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.

Answer 3

This is my attempt at making sense of this after reading the other two answers here.

If you're wondering about when to use the MSG_CONFIRM flag, essentially, all it does is tell the underlying ARP network layer to NOT periodically verify the MAC of the recipient IP, because we are confident the IP we are sending to is the device we think it is, since this message are are sending is in direct response to a message we just received from them! In other words, if in doubt, leave OUT the MSG_CONFIRM flag. Put it in ONLY if the message we are sending is a direct response to a message received, and therefore we want to increase the network efficiency a tiny bit by NOT verifying the MAC again periodically, at the risk that the destination MAC could change and be wrong and no loner match the IP address for the device we think we are sending this message to!

Pros of using MSG_CONFIRM:

1. It increases the efficiency of the network by NOT having ARP reprobe for the MAC of the destination address.

Cons or risks of using MSG_CONFIRM:

1. It may mean that if the old device on the network drops off, and a new destination device pops up on the network with the same destination address as the old one, but with a different hardware MAC, we won't know, because MSG_CONFIRM tells ARP not to reprobe that IP address's MAC.

When MSG_CONFIRM can be used:

1. When our message out is a direct reply to a message we just received in from that device, so we are sure its MAC is still correct.
2. MSG_CONFIRM in this case can be thought of as a "confirmation" message to the sender that we got their previous message.

Official documentation from here for sendto(): https://linux.die.net/man/2/sendto (emphasis added):

MSG_CONFIRM (Since Linux 2.3.15)

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 only implemented for IPv4 and IPv6. See arp(7) for details.

So, my rule of thumb is: just don't use it. It has little benefit. But, if you choose to use it, only use it to reply (via a UDP message) directly to the sender of a UDP message just received via recvfrom(), or equivalent.