NFD

There is a small problem. At the moment packet is transmitted to the face, there is no longer information about where the packet came from... Therefore, we have to somehow start tracking the face for each received packet... Another option, we have to make decision about the local control header somewhere in the Forwarder.

This task has Category=Forwarding.

Attaching incoming FaceId is part of forwarding, not part of face.

For now (to not block testing), I would suggest ignoring this problem and re-use the same LocalControlHeader for all faces that enabled localcontrolheder.

I'm working on a solution for this. The idea is to use non-consecutive memory block within the same send operation (this is actually supported by boost::asio).

Btw. The problem you mentioned does not really exist. When face has not control header enabled, the current API provides a way to send just wire format of Interest/Data. Basically, you should use condition and either directly use interest.wireEncode() or interest.getLocalControlHeader().wireEncode(interest).

Consider the following:

1. Interest arrives with nexthopFaceId field.
2. Interest is forwarded to a face which needs incomingFaceId.

It's wrong to have nexthopFaceId field in an outgoing packet.

For now, I'll copy every packet.

I disagree with this proposal due to the following reasons:

• The performance gain is negligible compared to 359,1 when LocalControlHeader is not enabled on a face. The saving is one conditional statement.
• There is no benchmark showing the current design has a bottleneck due to the addition of LocalControlHeader.
• The proposal complicates the implementation of every Face type that may be used for local. Instead of one TcpFace class, it requires a TcpFace class for remote communication, and a TcpLocalFace class for local communicate. This contradicts with simplicity design goal.

I would argue about simplicity. Forcing every face to deal (implicitly or explicitly) with local control header is wrong. TcpFace that is used for local communications should be different from face that is used for non-local. The clearer this distinction, less errors (I mean security errors) people will be able to make.

http://gerrit.named-data.net/#/c/359/1 is no less confusing, btw. And it is also kind of wrong, since Face's sendInterest/Data calls will never be called (they are virtual). Making them non-virtual eliminates an opportunity for custom face implementation to deal with Interest/Data directly as they wish...

Whether a Face is local or not is a policy decision. It has nothing to do with the underlying protocol. You are using the same TCP for local and non-local communications, so there is no fundamental difference.

Face::sendInterest and Face::sendData are virtual. However, not every Face implementation needs to override them.

A Face implementation can choose to:

• override Face::sendLinkPacket, to send the packet with LocalControlHeader attached if enabled -- UNIX and TCP must use this
• or, override Face::sendInterest and Face::sendData, so that it can process Interest and Data differently, but cannot attach LocalControlHeader -- multicast must use this