NFD

Do we need an Error class in transport.hpp? I don't find the Error in both lp-face and transport.

Answer to note-5:

If Transport::Error is needed, it can be added at the first commit that requires it.

We don't have to add everything in #3088.

feature-lp branch is gone, should I push to master?

MulticastUdpTransport has been made always permanent, should I do the same for EthernetTransport?

20151006 conference call decides: Change for this issue should be uploaded to master branch.

This is a breaking change, so a 5-day notice on nfd-dev will be needed before merging.

EthernetTransport should be permanent because of its semantics.

how can the link service slicer know the MTU of the underlying interface/transport?

I'm thinking about adding a getter to Transport class:

/** \return maximum payload size
 *  \retval -1 transport has no limit on payload size
 *
 *  The maximum payload size is usually the Maximum Transmission Unit (MTU) of a datagram-based transport, and unlimited (-1) for a stream-based transport.
 *  Blocks larger than this size may be dropped when attempting to send through this transport.
 *
 *  The return value should account for any overhead introduced by the transport.
 *  For example, total length of an IPv4 packet is limited to 65535 octets, but the IPv4 header and UDP header should be deducted from this size.
 */
ssize_t getMtu() const;

Junxiao Shi wrote:

how can the link service slicer know the MTU of the underlying interface/transport?

I'm thinking about adding a getter to Transport class:

/** \return maximum payload size
 *  \retval -1 transport has no limit on payload size
 *
 *  The maximum payload size is usually the Maximum Transmission Unit (MTU) of a datagram-based transport, and unlimited (-1) for a stream-based transport.
 *  Blocks larger than this size may be dropped when attempting to send through this transport.
 *
 *  The return value should account for any overhead introduced by the transport.
 *  For example, total length of an IPv4 packet is limited to 65535 octets, but the IPv4 header and UDP header should be deducted from this size.
 */
ssize_t getMtu() const;

I agree with putting this in the Transport class. It will help with fragmentation.

Junxiao Shi wrote:

EthernetTransport should be permanent because of its semantics.

This is actually much less trivial than I thought. In gerrit/2496 I ignored some of the easily ignorable errors, but there are some cases in which it is not so simple to decide what to do, and could require some design discussion. Moreover, extensive testing would be needed and I don't have so much free time right now. So, to avoid any risk of delaying the 0.4.0 release, I recommend to split "permanent EthernetTransport" into a separate task to be done after the release, and keep the current "persistent" implementation for now.

wrt getMtu, do we want to handle dynamic-MTU links (i.e. the MTU changes during the lifetime of the Transport)?

Junxiao Shi wrote:

LinkService should call Transport::getMtu every time it performs fragmentation or otherwise needs to know MTU, and should not store this return value.

However, there's no signal to indicate a change in MTU.

Polling a network interface for its MTU (using ioctl) every time a packet needs to be sent would be horribly inefficient.

A better solution (although Linux-only, as usual I don't know and don't care about OS X) would be to subscribe to rtnetlink notifications for link MTU changes. However this should be considered a new feature, and it would complicate the transport implementation a bit.

Polling a network interface for its MTU (using ioctl) every time a packet needs to be sent would be horribly inefficient.

No, EthernetTransport::getMtu should not call ioctl every time.

For now, it only needs to call ioctl during initialization, and store the result in a member variable; then getMtu can just return this variable.

Subscribing to rtnetlink can be considered in the future.

Ok so the answer to my question in note-18 is "no (for now)". It definitely seemed like the opposite from what you said initially.