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

Feature Request: mdns in libp2p #572

Closed
remmerw opened this issue Sep 3, 2023 · 6 comments
Closed

Feature Request: mdns in libp2p #572

remmerw opened this issue Sep 3, 2023 · 6 comments

Comments

@remmerw
Copy link

remmerw commented Sep 3, 2023

The current implementation of mDNS in libp2p (go) publish a set of multi addresses.
The multi addresses are not encoded and probably consume more bytes then an encoded version (like the addresses in identity proto)
Does it make sense to publish the identity instead of publishing the plain multi address?
Nice benefit would be, that the peers protocols are known before dialing the peer.

@thomaseizinger
Copy link
Contributor

mDNS packets have a size limit so we need to take that into account. Overall, I'd say this sounds like a new spec to me rather than changing the existing one.

mDNS is cool but ultimately a not very important discovery mechanism IMO. It would be more useful to push things like #498 forward which allows all connections to benefit from decreased latency until they receive the identify info.

@marten-seemann
Copy link
Contributor

Reducing the handshake latency is not really interesting on local networks, since the RTT is so small anyway. It matters much more on the public internet.

@thomaseizinger
Copy link
Contributor

Reducing the handshake latency is not really interesting on local networks, since the RTT is so small anyway.

Right, that leads us to the same conclusion though :)
Optimising mDNS to include identify info isn't really worth it because it only works on local networks so you might as well just do another RT and fetch identify regularly.

@marten-seemann
Copy link
Contributor

@thomaseizinger I agree with you, I was just adding to your point :)

@remmerw
Copy link
Author

remmerw commented Sep 4, 2023

I try to understand the proposal #498
.
Is it a requirement for use the early data feature to had an existing connection before, so that early data is possible?
Probably not the forum to ask questions. Feel free to close the entry. I got my answer.

@marten-seemann
Copy link
Contributor

Is it a requirement for use the early data feature to had an existing connection before, so that early data is possible?

It is not. It's all explained in #498 (0.5-RTT section).

Closing this issue here since there's nothing actionable.

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

No branches or pull requests

3 participants