NFD

What address should I use for the non-local properties tests?

What address should I use for the non-local properties tests?

A real IP address would be needed. Using an arbitrary IP that doesn't exist on the host would result in bind failure.

There are a few options in obtaining a real IP:

SOLUTION A

Enumerate network interfaces on the host, and use one of them.

Benefit: Implementation is easy.

Drawback: Test case would be skipped if the host has no IPv4 or IPv6 interface other than loopback.

Drawback: Possible tests for MulticastUdpTransport and EthernetTransport are limited.

SOLUTION B

Create a TUN interface, and test on this interface.

Benefit: Test case does not depend on host configuration.

Benefit: It's possible to simulate remote hosts over TUN interface. Thus, there's more flexibility in what scenarios are possible.

Drawback: Test scenario depends on the availability of TUNTAP kernel module. It's available on most platforms, but unavailable by default in OpenVZ containers.

Drawback: Implementation is much harder (12 hours shared among all test suites that depend on TUN).

Current time estimation assumes SOLUTION A, but this choice needs further discussion.

Definitely solution A, in my opinion. And you should use listNetworkInterfaces().

20151117 conference call decides to use note-8 SOLUTION A.

The limitation about MulticastUdpTransport can be resolved with LOOPBACK socket option.

Design question on http://gerrit.named-data.net/2612 patch set #1: do you intend to share some code between TcpTransport test suite and UnixStreamTransport test suite (some test cases will look very similar)? If so, how?

Davide Pesavento wrote:

Design question on http://gerrit.named-data.net/2612 patch set #1: do you intend to share some code between TcpTransport test suite and UnixStreamTransport test suite (some test cases will look very similar)? If so, how?

Currently, I have no plans to do so, as they use different transports, but I might do so if I find many similarities when implementing the UnixStreamTransport tests. I'm currently trying to get the Receive tests in TcpTransport to even work at all.

Eric Newberry wrote:

Currently, I have no plans to do so, as they use different transports

Sure, but they both derive from StreamTransport, where most of the code is.

but I might do so if I find many similarities when implementing the UnixStreamTransport tests.

Ok, this is perfectly reasonable. It should make it easier to spot the similarities between the two test suites, and it'll also simplify the code review.