Task #5041
closedRedefine EndpointId as variant<monostate, ethernet::Address, udp::Endpoint>
100%
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.
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
.
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?
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.
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
Updated by Alex Afanasyev over 4 years ago
- Blocks Feature #4973: Self-learning: switch from multicast to unicast on Wi-Fi infrastructure added
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?
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?
Updated by Davide Pesavento over 4 years ago
In any case, adding monostate
is fine with me.
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?
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?..
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.
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.
Updated by Davide Pesavento over 4 years ago
- Status changed from New to Code review
Updated by Davide Pesavento over 3 years ago
- Target version changed from 22.02 to 22.12
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)
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
Updated by Davide Pesavento 12 months ago
- Tags changed from SelfLearning to self-learning