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.

Sign up for GitHub

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

Jump to bottom

mdns peer discovery is not compliant to latest specification #1232

Closed
shresthagrawal opened this issue Aug 29, 2019 · 1 comment
Closed

mdns peer discovery is not compliant to latest specification #1232

shresthagrawal opened this issue Aug 29, 2019 · 1 comment
Labels
bug

Comments

@shresthagrawal
Copy link

shresthagrawal commented Aug 29, 2019 •
edited
Loading

If the encoding of the peer's ID exceeds 63 characters, then the Split at 63rd character workaround can be used.

The specs for encoding PeerID greater than 63 character requires to perform split and join with a '.' but the current implementation doesn't handle such condition!
@tomaka tomaka added the bug label Aug 29, 2019
@raulk raulk mentioned this issue Aug 29, 2019
Open
@peat peat mentioned this issue Oct 24, 2019
Merged
tomaka pushed a commit that referenced this issue Oct 31, 2019
@peat @tomaka
[mdns] - Support for long mDNS names (Bug #1232) (#1287)
eb7b7bd 
* Dead code -- commenting out with a note referencing future implementation

* Adding "std" feature so that cargo can build in other directories (notably `misc/mdns`, so that I could run these tests)

* Permitting `PeerID` to be built from an `Identity` multihash

* The length limit for DNS labels is 63 characters, as per RFC1035

* Allocates the vector with capacity for the service name plus additional QNAME encoding bytes

* Added support for encoding/decoding peer IDs with an encoded length greater than 63 characters

* Removing "std" from ring features

Co-Authored-By: Pierre Krieger <[email protected]>

* Retaining MAX_INLINE_KEY_LENGTH with comment about future usage

* `segment_peer_id` consumes `peer_id` ... plus an early return for IDs that don't need to be segmented

* Fixing logic
tomaka pushed a commit to tomaka/libp2p-rs that referenced this issue Nov 6, 2019
@peat @tomaka
[mdns] - Support for long mDNS names (Bug libp2p#1232) (libp2p#1287)
c7f18b3 
* Dead code -- commenting out with a note referencing future implementation

* Adding "std" feature so that cargo can build in other directories (notably `misc/mdns`, so that I could run these tests)

* Permitting `PeerID` to be built from an `Identity` multihash

* The length limit for DNS labels is 63 characters, as per RFC1035

* Allocates the vector with capacity for the service name plus additional QNAME encoding bytes

* Added support for encoding/decoding peer IDs with an encoded length greater than 63 characters

* Removing "std" from ring features

Co-Authored-By: Pierre Krieger <[email protected]>

* Retaining MAX_INLINE_KEY_LENGTH with comment about future usage

* `segment_peer_id` consumes `peer_id` ... plus an early return for IDs that don't need to be segmented

* Fixing logic
tomaka added a commit that referenced this issue Nov 6, 2019
@tomaka
Cherry-pick commits from master to stable-futures (#1296)
c1226b2 
* Implement Debug for (ed25519|secp256k1)::(Keypair|SecretKey) (#1285)

* Fix possible arithmetic overflow in libp2p-kad. (#1291)

When the number of active queries exceeds the (internal)
JOBS_MAX_QUERIES limit, which is only supposed to bound
the number of concurrent queries relating to background
jobs, an arithmetic overflow occurs. This is fixed by
using saturating subtraction.

* protocols/plaintext: Add example on how to upgrade with PlainTextConfig1 (#1286)

* [mdns] - Support for long mDNS names (Bug #1232) (#1287)

* Dead code -- commenting out with a note referencing future implementation

* Adding "std" feature so that cargo can build in other directories (notably `misc/mdns`, so that I could run these tests)

* Permitting `PeerID` to be built from an `Identity` multihash

* The length limit for DNS labels is 63 characters, as per RFC1035

* Allocates the vector with capacity for the service name plus additional QNAME encoding bytes

* Added support for encoding/decoding peer IDs with an encoded length greater than 63 characters

* Removing "std" from ring features

Co-Authored-By: Pierre Krieger <[email protected]>

* Retaining MAX_INLINE_KEY_LENGTH with comment about future usage

* `segment_peer_id` consumes `peer_id` ... plus an early return for IDs that don't need to be segmented

* Fixing logic

* Bump most dependencies (#1268)

* Bump most dependencies

This actually builds 😊.

* Bump all dependencies

Includes the excellent work of @rschulman in #1265.

* Remove use of ed25519-dalek fork

* Monomorphize more dependencies

* Add compatibility hack for rand

Cargo allows a crate to depend on multiple versions of another, but
`cargo-web` panics in that situation.  Use a wrapper crate to work
around the panic.

* Use @tomaka’s idea for using a newer `rand`

instead of my own ugly hack.

* Switch to Parity master

as its dependency-bumping PR has been merged.

* Update some depenendencies again

* Remove unwraps and `#[allow(deprecated)]`.

* Remove spurious changes to dependencies

Bumping minor or patch versions is not needed, and increases likelyhood
of merge conflicts.

* Remove some redundant Cargo.toml changes

* Replace a retry loop with an expect

`ed25519::SecretKey::from_bytes` will never fail for 32-byte inputs.

* Revert changes that don’t belong in this PR

* Remove using void to bypass ICE (#1295)

* Publish 0.13.0 (#1294)
@tomaka
Copy link
Member

tomaka commented Jan 7, 2020

Done in #1287 I believe.

@tomaka tomaka closed this as completed Jan 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tomaka @shresthagrawal