NFD

What do you mean by "initialization logic"? I'm not certain what that term is referring to.

Answer to note-5:

When reading code, try to understand how a face is created, since the beginning.

A face creation is triggered by (a) loading configuration (multicast faces only), (b) accepting incoming connection, or (c) faces/create management command.

"initialization logic" is a vague concept. It includes but is not limited to:

• create a socket (eg. TCP socket, pcap handle, not the Socket class)
• initialize the socket (eg. connect, set socket options)
• make a Face subclass instance usable with the socket; in new design, make a Socket subclass instance usable

When you design new initialization logic and decide on the boundary between Socket subclass and its caller (eg. Channel subclass), keep in mind the Socket must be able to recover from an error (eg. broken TCP connection needs reestablished) on its own (when it's configured to have persistency=permanent).

#2222 note-40 design has been approved. All items in this Task can proceed.

There is still possibility for Socket to be renamed, but that would be a minor change without affecting structure.

What is a NetworkAddress, as referred to in the high-level design? Is it the address based upon the socket type (like IP address for TCP and UDP)?

Answer to note-10:

What is a NetworkAddress?

See #2222 note-45 for design intention.

In this Task, only remoteAddr on incoming packets is necessary (it will be used in #3104 for reassembly);
localAddr, and remoteAddr on outgoing packets can be ignored.

Is it the address based upon the socket type (like IP address for TCP and UDP)?

Yes, but LinkService shouldn't care about the socket type, so NetworkAddress shall be a single type that can represent an address of any socket type.

Reference ns3::Address for how to design NetworkAddress data structure.

There's an error in UdpSocket: we don't set the DF flag, we disable PMTU discovery, which has the opposite effect since it prevents the kernel from setting the DF flag.

20150821 conference call decides that we should prefer the gradual approach in note-14.

I'm not sure how to read the second diagram. Is it a sort of chain of responsibility (who does what)? A timeline?

Be careful that in most cases it's actually the channel, not the face, that instantiates the Asio socket and then passes (moves) it to the face constructor. This is especially important (and inevitable) for stream-based transports, due to async_accept() requirements. Conversely, it isn't technically needed for the UDP face/channel, if I remember correctly, but was implemented in the same way for consistency reasons.

Davide Pesavento wrote:

I'm not sure how to read the second diagram. Is it a sort of chain of responsibility (who does what)? A timeline?

From what I understood from my meeting with Junxiao on Friday, it's a chain of instantiation, similar to the one about the existing Face system in the NFD Developer Guide. For example, for unicast the Factory creates a Channel, which then listens for incoming connections, creating a Face upon acceptance of the connection. I need to move the Socket creation into the Channel for unicast connections (see below).

Be careful that in most cases it's actually the channel, not the face, that instantiates the Asio socket and then passes (moves) it to the face constructor. This is especially important (and inevitable) for stream-based transports, due to async_accept() requirements. Conversely, it isn't technically needed for the UDP face/channel, if I remember correctly, but was implemented in the same way for consistency reasons.

I wasn't aware of this. I'll modify my design to fit this requirement.

Comment on note-16:

There shouldn't be TcpFace UdpFace UnixFace EthernetFace WebSocketFace.

Quote issue description:

Implement a non-inheritable Face class that connects a LinkService and Socket.

There is only one non-inheritable Face class. The behavior of a Face is entirely defined by the LinkService and Socket used to construct it.

note-20 design appears to be correct.

I have finished up to and including part 1 of note 14. Will a feature branch be used or should I submit the commit to the master branch?

feature-lp branch is created.

The design in #2222 note 57 appears to cause circular dependencies, as link-service.hpp needs to include lp-face.hpp and transport.hpp needs to include lp-face.hpp, but lp-face.hpp needs to include link-service.hpp and transport.hpp.

Answer to note-50:

1. forward declare LpFace in link-service.hpp and transport.hpp
2. include lp-face.hpp in link-service.cpp and transport.cpp

Transport::Packet doesn't work well with forward declarations. We could possibly work around this by removing Packet as an inner class and adding it as a normal class?

Answer to note-52:

lp-face.hpp and link-service.hpp can still include transport.hpp, so that Transport::Packet is never forward-declared.

LpFaceWrapper needs another getter (see #3168 note-23 for reason):

LpFace*
getLpFace();

Note: it's unnecessary to declare a const version because there's no use case.

From Eric's post in http://gerrit.named-data.net/2423 patchset18:

I believe with this current design, NFD_LOG_FACE would need to be defined in each file, as FaceLogHelper requires a template argument.

No. As given in note-49, NFD_LOG_FACE* macros appear in face-log.hpp only, and this header is included by face.hpp, transport.hpp, link-service.hpp.