NFD

http://gerrit.named-data.net/2505

I'm doing an initial implementation in commit:057807d9dc25f388baef17a49a9b360ed36bff1f, but I run into a problem on how to elegantly calculate the MTU for UDP.

The algorithm is simple:

  size_t mtu = 0;
  if (m_socket.local_endpoint().address().is_v4()) { // IPv4
    mtu = std::numeric_limits<uint16_t>::max(); // maximum value in total length field
    mtu -= 20; // size of IPv4 header without options
  }
  else { // IPv6
    mtu = std::numeric_limits<uint16_t>::max(); // maximum value in payload length field
  }
  mtu -= 16; // size of UDP header
  this->setMtu(mtu);

But,
The algorithm contains several magic numbers (violates rule 3.17).
An alternate is to pull in headers for IPv4/IPv6/UDP headers and use decltype sizeof on relevant fields, but I'm worrying about them being platform dependent.

Also,
The algorithm does not consider the overhead from IPv4 options.

Another issue is:
UnicastUdpTransport and MulticastUdpTransport both need this algorithm, but their common base class is DatagramTransport which is not the right place to put this algorithm.
I have 3 alternatives:

• create a template<typename Addressing> UdpTransport class template as the base class and put this logic in its constructor
• add udp-protocol.hpp and make this logic as a free function
• create a template<typename Protocol> getMtu(socket) function template, and specialize it for UDP

I need suggestions on these issues before I can continue.

Junxiao Shi wrote:

The algorithm contains several magic numbers (violates rule 3.17).

This is a non-problem. It's perfectly clear what the algorithm is about and what the numbers are, there's nothing magic about them.

An alternate is to pull in headers for IPv4/IPv6/UDP headers and use decltype sizeof on relevant fields, but I'm worrying about them being platform dependent.

No, don't over-engineer it please. Besides, the names of the structs that represent the UDP/IP headers are probably not portable, so it would become a mess of ifdefs.

Also,
The algorithm does not consider the overhead from IPv4 options.

True, although IPv4 options are seldom used as far as I know. Unfortunately we cannot know in advance if the kernel or an intermediate router will add any options, therefore we can play it safe and subtract the maximum IP header length allowed (60 bytes). It doesn't really matter anyway since the max NDN packet size is 8800 bytes...

• create a template<typename Addressing> UdpTransport class template as the base class and put this logic in its constructor

This seems to be the cleanest solution (I assume UdpTransport will be a subclass of DatagramTransport).