Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ENR Record.init and update call for dual stack #748

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kdeme
Copy link
Contributor

@kdeme kdeme commented Oct 11, 2024

Attempt to add dual stack support in ENR in line with the current API.
In draft however as I don't really like this API, it feels rather clumsy, both in implementation and in usage.

I'll probably implement dualstack in Fluffy to see how it would typically be used, and continue/adjust from there.

Might also go for some EnrBuilder approach instead to get to something in the trend of:

let enr = EnrBuilder.init().tcp4(Port(9000)).ip4(ip4).ip6(ip6).build(privatekey)

and

let enrUpdated = EnrBuilder.init(enr).tcp4(Port(9000)).ip4(ip4).build(privatekey)

Ideas and/or use cases are welcome.

Comment on lines +262 to +263
ip4: array[4, byte],
ip6: array[16, byte],
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no Opt here, as in dual stack case I'm assuming both IPs or no IP is known (perhaps this is not correct?).

Also not using IpAddress as from that type I cannot be sure whether it is IPv4 or IPv6 (unless I check for it of course).

In the other use cases, the init call with only 1 address can be used.

Comment on lines +291 to +293
# From the ENR specification:
# "Declaring the same port number in both tcp, tcp6 or udp, udp6 should be avoided
# but doesn't render the record invalid."
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I don't need to do this check and can let the user decide what they want to do in case of same ports.

Comment on lines +428 to +429
## Providing an `Opt.none` for `tcp4Port`/`udp4Port`/`tcp6Port`/`udp6Port`/
## will leave the corresponding field untouched.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps it makes more sense to unset the field in that case

udp6Port: Opt[Port] = Opt.none(Port),
extraFields: openArray[FieldPair] = []):
EnrResult[void] =
## Update a `Record` with given IPv4 and IPv6 address, optional TCP port and
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that I have to write such a lengthy documentation for this call probably is not a sign of good API.

@NagyZoltanPeter
Copy link

Attempt to add dual stack support in ENR in line with the current API. In draft however as I don't really like this API, it feels rather clumsy, both in implementation and in usage.

I'll probably implement dualstack in Fluffy to see how it would typically be used, and continue/adjust from there.

Might also go for some EnrBuilder approach instead to get to something in the trend of:

let enr = EnrBuilder.init().tcp4(Port(9000)).ip4(ip4).ip6(ip6).build(privatekey)

and

let enrUpdated = EnrBuilder.init(enr).tcp4(Port(9000)).ip4(ip4).build(privatekey)

Ideas and/or use cases are welcome.

@kdeme
Thanks for the effort! From Waku point of view I have gone through it.
From our POV I would really vote for the builder pattern than anything else. In Waku we have something similar implemented over enr.Record. But the approach you crafter here, above it might be even better.
I think it has greater advantages controlling what can get into the ENR or filtering duplicates, fine graining updates (with Opt.none for clearing a field).

For the draft solution, I have the feeling that making IP4 and IP6 mandatory we will still end up in incompatibilities/regression. Do you see dual stack to be forced?

@arnetheduck
Copy link
Member

arnetheduck commented Oct 18, 2024

Do you see dual stack to be forced?

re ipv6, the idea in general is to push towards a world where dual stack is enabled by default (if the platform allows it), ie if the caller or user does "nothing special", they should end up in a dual stack world that serves both ipv4 and ipv6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants