Project

General

Profile

Actions

Bug #3367

closed

IPv6 test cases should be skipped if IPv6 is not available

Added by Alex Afanasyev over 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Category:
Faces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

Travis-CI does not have any support for IPv6... not even on loopback interfaces.

This results in several failures in test cases, e.g. from https://travis-ci.org/named-data/NFD/builds/105011116

Entering test suite "TestTcpTransport"
Entering test case "StaticPropertiesLocalIpv4"
1453846242.616016 INFO: [TcpTransport] [id=0,local=tcp4://127.0.0.1:33324,remote=tcp4://127.0.0.1:7070] Creating transport
Leaving test case "StaticPropertiesLocalIpv4"
Entering test case "StaticPropertiesLocalIpv6"
unknown location(0): fatal error in "StaticPropertiesLocalIpv6": std::runtime_error: bind: Cannot assign requested address
Leaving test case "StaticPropertiesLocalIpv6"

... ...

Entering test suite "TestUnicastUdpTransport"
Entering test case "StaticPropertiesLocalIpv4"
1453846242.621958 INFO: [UnicastUdpTransport] [id=0,local=udp4://127.0.0.1:36982,remote=udp4://127.0.0.1:7070] Creating transport
Leaving test case "StaticPropertiesLocalIpv4"
Entering test case "StaticPropertiesLocalIpv6"
unknown location(0): fatal error in "StaticPropertiesLocalIpv6": std::runtime_error: connect: Network is unreachable
Leaving test case "StaticPropertiesLocalIpv6"

We should add guards to skip the affected tests when IPv6 is not available at all.

Actions #1

Updated by Davide Pesavento about 8 years ago

  • Tracker changed from Task to Bug
  • Description updated (diff)
  • Target version changed from v0.4 to v0.5
  • Start date deleted (12/21/2015)

The "NonLocalIp" tests already have guards in v0.4.0. We need to add similar guards to the "LocalIp" test cases.

Actions #2

Updated by Davide Pesavento about 8 years ago

  • Status changed from New to Code review
  • Assignee set to Davide Pesavento
  • % Done changed from 0 to 50

Not sure if this is the approach we want to take... http://gerrit.named-data.net/2779

Actions #3

Updated by Junxiao Shi about 8 years ago

Snippet from NFD:commit:ba9e4a4097726ea15a43d6acd7dc89e6664f8723 :

template<typename A>
A
getAvailableInterfaceIp(bool wantLoopback = false, bool needMulticast = false);

I'm not particularly happy with the two boolean arguments of getAvailableInterfaceIp()... they're not very self-descriptive at the call sites.

One solution is:

enum AvailableInterfaceFlags {
  AVAILABLE_INTERFACE_NONE = 0,
  AVAILABLE_INTERFACE_LOOPBACK = (1 << 0),
  AVAILABLE_INTERFACE_MCAST = (1 << 1)
};

template<typename A>
A
getAvailableInterfaceIp(AvailableInterfaceFlags flags);
Actions #4

Updated by Davide Pesavento about 8 years ago

Junxiao Shi wrote:

One solution is:

enum AvailableInterfaceFlags {
  AVAILABLE_INTERFACE_NONE = 0,
  AVAILABLE_INTERFACE_LOOPBACK = (1 << 0),
  AVAILABLE_INTERFACE_MCAST = (1 << 1)
};

Is this powerful enough though? I think we actually need 3 states for each network interface trait:

  • yes, the trait must be present
  • no, the trait must not be present
  • don't care, the trait can be present or not, it doesn't matter
Actions #5

Updated by Junxiao Shi about 8 years ago

Reply to note-4:

It's as powerful as two booleans.

The complaint quoted in note-3 is about code readability, not about flexibility.

Actions #6

Updated by Davide Pesavento about 8 years ago

Absolutely. But since we're talking about the API, I wanted to go one step further and make it more flexible.

Also note that the two booleans in the current patch are named differently because they have different semantics when their values are set to false.

Actions #7

Updated by Junxiao Shi almost 8 years ago

flexibility == complexity

Current use cases do not need flexibility, but only need readability.

Actions #8

Updated by Davide Pesavento almost 8 years ago

  • % Done changed from 50 to 60

I've experimented with Boost.Parameter library but I gave up because it doesn't seem to be usable with function templates and specializations.

http://gerrit.named-data.net/2779 PS3 proposes a more self-descriptive API based on enumerators (see test-ip.hpp).

Actions #9

Updated by Davide Pesavento almost 8 years ago

  • % Done changed from 60 to 100

Change is complete.

Actions #10

Updated by Junxiao Shi almost 8 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF