NFD

Two design questions on https://gerrit.named-data.net/3809

1. TcpFactory and UdpFactory ignore the LocalUri even if it's provided, i.e. they accept everything. Is that ok or do we want to log a warning? or throw an exception (thus failing the command)? The latter would allow clients to determine if LocalUri selection is actually supported by the forwarder they're talking to, without relying on version number checks. It would also help preserve backward compatibility when the factories will start checking if the provided LocalUri makes sense (commands that were accepted won't suddenly start failing on the new version).

2. I guess we also need a way to tell the protocol factories whether the LocalUri was specified in the request or not. The current approach taken by Change 3809 is to pass a non-canonical FaceUri (null://). Alternatives are: use an "empty" FaceUri, use ndn::optional<FaceUri>, or introduce a new FaceUri scheme such as any:// that has the current semantics (the factory chooses a local endpoint).

note-10 questions come from incomplete protocol definition. My recommendations for protocol are:

• For now, protocol should require LocalUri only for Ethernet unicast faces, and forbid LocalUri for UDP and TCP faces.
• In the near future, 409-conflict response should carry LocalUri field.
• In the near future, Uri+LocalUri should be returned on successful face creation response, regardless of whether LocalUri was specified in the request. This would allow nfdc to display a good output without retrieving a faces/query dataset.
• In the future, LocalUri can be allowed on UDP and TCP face creation. If so, socket binding should reflect the choice in LocalUri.
• In the future, faces/create command can accept multicast face and NIC-associated permanent face creation. This would give more flexibility than through configuration.

Regarding implementation, ndn::optional<FaceUri> localUri should be passed to ProtocolFactory::createFace. TcpFactory and UdpFactory should throw an exception when localUri is supplied. EthernetFactory should throw an exception when localUri is missing.

I agree with all what Junxiao said, just want to add specifics regarding "protocol forbids". Right now, the command should fail and return to client whatever error code and description. If we use in protocol factories exceptions for this, then exception should be perfect.

Optional for not specified local URI sounds good.

I agree that LocalUri should be forbidden or UDP and TCP faces and that including the LocalUri with these faces should cause an exception and command failure.

ndn::optional sounds better than any:// as well.

Alex Afanasyev wrote:

If we use in protocol factories exceptions for this, then exception should be perfect.

An exception would do the job, meaning that it would fail the face create command. However the error returned to the client would be something like "internal server error", which is not really correct. On the other hand, triggering the FaceCreationFailedCallback from ProtocolFactory::createFace concrete implementations allows specifying a different status code, so that's probably better.