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

[wip] iroh-memesync #586

Closed
wants to merge 709 commits into from
Closed

[wip] iroh-memesync #586

wants to merge 709 commits into from

Conversation

dignifiedquire
Copy link
Contributor

Opening this mostly for visibility, but it does transfer some bytes around

Closes n0-computer/beetle#59

Copy link

@hannahhoward hannahhoward left a comment

Choose a reason for hiding this comment

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

I'm sure you don't expect anyone reviewing this but it's fun to follow a long your work. Generally looks awesome.

}

#[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize, Hash)]
pub struct QueryId(u64);

Choose a reason for hiding this comment

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

make it a UUID... you'll be happy you did in the future :P

  • some rando browsing this code

Copy link
Contributor Author

Choose a reason for hiding this comment

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

what would be the practical benefit? this only needs to be unique for the sender-receiver pair, and even if it is not, not much bad happens. uuids are considerably larger though

Choose a reason for hiding this comment

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

we had uints as graphsync ids originally.
we eventual made it a UUID, largely to remove a bunch of cruft code matching up IDs with layered protocols like go-data-transfer and filecoin retrieval. Plus I find tracking things with just a single id quite pleasant (as opposed to always appending peer ids)
yes they are larger, it's certainly a tradeoff, maybe not worth making now.
the nice thing about uuids is you can share them between layered or seperate protocols.

impl Message {
/// Decoding from a given `BytesMut`.
pub fn from_bytes(bytes: BytesMut) -> Result<Self, Error> {
let msg = bincode::deserialize(&bytes)?;

Choose a reason for hiding this comment

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

CBOR? Just for cross language compatibility maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am still very undecided on the format, not a big fan of cbor, so for now this is a placeholder encoding

flub and others added 5 commits January 2, 2023 12:35
Newer clippy wants the identifiers in the format string when
possible.  Boring change but why not.
This makes sure to await the future from async_channel::Sender::send.
When not awaiting this only makes a struct and noting is ever sent.

Caught by clippy really.
Updates the requirements on [sysinfo](https://github.com/GuillaumeGomez/sysinfo) to permit the latest version.
- [Release notes](https://github.com/GuillaumeGomez/sysinfo/releases)
- [Changelog](https://github.com/GuillaumeGomez/sysinfo/blob/master/CHANGELOG.md)
- [Commits](https://github.com/GuillaumeGomez/sysinfo/commits)

---
updated-dependencies:
- dependency-name: sysinfo
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Floris Bruynooghe <[email protected]>
Updates the requirements on [rlimit](https://github.com/Nugine/rlimit) to permit the latest version.
- [Release notes](https://github.com/Nugine/rlimit/releases)
- [Changelog](https://github.com/Nugine/rlimit/blob/master/CHANGELOG.md)
- [Commits](Nugine/rlimit@v0.8.3...v0.8.3)

---
updated-dependencies:
- dependency-name: rlimit
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Floris Bruynooghe <[email protected]>
Updates the requirements on [base64](https://github.com/marshallpierce/rust-base64) to permit the latest version.
- [Release notes](https://github.com/marshallpierce/rust-base64/releases)
- [Changelog](https://github.com/marshallpierce/rust-base64/blob/master/RELEASE-NOTES.md)
- [Commits](marshallpierce/rust-base64@v0.13.1...v0.13.1)

---
updated-dependencies:
- dependency-name: base64
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Floris Bruynooghe <[email protected]>
Arqu and others added 2 commits January 4, 2023 15:38
flub and others added 10 commits January 4, 2023 20:07
We used to use the same config for the service and server (aka the
binary).  This is confusing when creating configs to use with
e.g. iroh-one, iroh-embed or iroh-share because some fields are not
used.

This splits off the config structs to avoid this problem, services now
have a Config and binaries a ServerConfig.  This allows creating the
services standalone without all the baggage a server needs.

While this isn't many fields yet, this will get worse as we add more
features (this is split off from another PR where this seemed useful).
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.

implement first version of memesync