Project

General

Profile

Actions

Task #5041

closed

Redefine EndpointId as variant<monostate, ethernet::Address, udp::Endpoint>

Added by Teng Liang about 5 years ago. Updated 12 months ago.

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

100%

Estimated time:

Description

To achieve creating unicast Face in self-learning strategy (see motivation in #4973), EndpointId, i.e., a remote ethernet or udp address, has to be passed in. The current type of EndpointId is int, and this issue intends to redefine it as variant<monostate, ethernet::Address, udp::Endpoint> as discussed in 2019-11-25 NFD call.


Related issues 1 (1 open0 closed)

Blocks NFD - Feature #4973: Self-learning: switch from multicast to unicast on Wi-Fi infrastructureNew

Actions
Actions #1

Updated by Davide Pesavento almost 5 years ago

  • Category set to Faces
  • Start date deleted (10/31/2019)

Teng Liang wrote:

Mapping UDP6 (142-bit) to EndpointId (64-bit) is challenging, so is the reverse mapping.

Why is it challenging?

However, if EndpointId is redefined as string, then we can define EndpointId with the following format:

I really dislike using strings unless absolutely necessary. Also keep in mind that this means converting the remote address to a string, converting the port number to a string, and combining the two strings, all of this for every packet received on a multicast face.

If we need to change EndpointId type, I suggest using a variant.

Actions #2

Updated by Teng Liang almost 5 years ago

Davide Pesavento wrote:

Teng Liang wrote:

Mapping UDP6 (142-bit) to EndpointId (64-bit) is challenging, so is the reverse mapping.

Why is it challenging?

I don't see a simple way to do reverse mapping.

However, if EndpointId is redefined as string, then we can define EndpointId with the following format:

I really dislike using strings unless absolutely necessary. Also keep in mind that this means converting the remote address to a string, converting the port number to a string, and combining the two strings, all of this for every packet received on a multicast face.

If we need to change EndpointId type, I suggest using a variant.

So how about variant<int64_t, int64_t*>, the former one is used for Ethernet and UDP4, and the latter one needs 3 64-bit for UDP6?

Actions #3

Updated by Teng Liang almost 5 years ago

  • Description updated (diff)
Actions #4

Updated by Davide Pesavento over 4 years ago

  • Status changed from New to Rejected

I'm rejecting this. I strongly disagree with using/manipulating strings on a per-packet basis at such a low layer of the forwarder. Moreover, this is made (partially) obsolete by https://gerrit.named-data.net/c/NFD/+/6070 if I understand correctly.

Actions #5

Updated by Alex Afanasyev over 4 years ago

  • Subject changed from Redefine EndpointId as a string to Redefine EndpointId as variant<ethernet::Address, ip::udp::endpoint>
  • Description updated (diff)
  • Status changed from Rejected to New
  • Target version set to 22.02
Actions #6

Updated by Alex Afanasyev over 4 years ago

  • Blocks Feature #4973: Self-learning: switch from multicast to unicast on Wi-Fi infrastructure added
Actions #7

Updated by Alex Afanasyev over 4 years ago

  • Assignee set to Teng Liang
Actions #8

Updated by Davide Pesavento over 4 years ago

  • Description updated (diff)
Actions #9

Updated by Teng Liang over 4 years ago

In most cases, EndpointId has empty value. How about defining it as variant<std::monostate, ethernet::Address, ip::udp::endpoint> to make it default constructible without values?

Actions #10

Updated by Davide Pesavento over 4 years ago

Teng Liang wrote:

In most cases, EndpointId has empty value.

I suppose these cases are remnants from our failed attempt at introducing EndpointId in forwarding and strategies?

Actions #11

Updated by Davide Pesavento over 4 years ago

In any case, adding monostate is fine with me.

Actions #12

Updated by Teng Liang over 4 years ago

Davide Pesavento wrote:

Teng Liang wrote:

In most cases, EndpointId has empty value.

I suppose these cases are remnants from our failed attempt at introducing EndpointId in forwarding and strategies?

The current EndpointId is 0 when a Face is not multicast. What's the equivalent value when using variant?

Actions #13

Updated by Alex Afanasyev over 4 years ago

Why couldn't we have a valid endpoint for all faces, which can simply be interpreted as "remote" (almost equal to RemoveFaceUri, just programmatical, instead for human interpretation). Could this simplify things?..

Actions #14

Updated by Davide Pesavento over 4 years ago

Teng Liang wrote:

Davide Pesavento wrote:

Teng Liang wrote:

In most cases, EndpointId has empty value.

I suppose these cases are remnants from our failed attempt at introducing EndpointId in forwarding and strategies?

The current EndpointId is 0 when a Face is not multicast. What's the equivalent value when using variant?

For non-multicast faces, the EndpointId value is meaningless and should never be used. So you could literally use any invalid address, it doesn't matter. But as I said, monostate is fine and makes the "invalid case" more explicit.

Actions #15

Updated by Davide Pesavento over 4 years ago

Alex Afanasyev wrote:

Why couldn't we have a valid endpoint for all faces, which can simply be interpreted as "remote" (almost equal to RemoveFaceUri, just programmatical, instead for human interpretation). Could this simplify things?..

We could do that, given that the information is available at the socket layer. But it would be kind of useless, as the rest of NFD doesn't use that information. So I'd leave this extension for later, if we ever need it.

Actions #16

Updated by Alex Afanasyev over 4 years ago

Agreed

Actions #17

Updated by Davide Pesavento over 4 years ago

  • Status changed from New to Code review
Actions #18

Updated by Davide Pesavento over 3 years ago

  • Target version changed from 22.02 to 22.12
Actions #19

Updated by Teng Liang over 2 years ago

  • Subject changed from Redefine EndpointId as variant<ethernet::Address, ip::udp::endpoint> to Redefine EndpointId as variant<monostate, ethernet::Address, ip::udp::endpoint>
  • Description updated (diff)
Actions #20

Updated by Davide Pesavento about 2 years ago

  • Subject changed from Redefine EndpointId as variant<monostate, ethernet::Address, ip::udp::endpoint> to Redefine EndpointId as variant<monostate, ethernet::Address, udp::Endpoint>
  • Description updated (diff)
  • Status changed from Code review to Closed
  • % Done changed from 0 to 100
Actions #21

Updated by Davide Pesavento 12 months ago

  • Tags changed from SelfLearning to self-learning
Actions

Also available in: Atom PDF