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 Ability To Manipulate Routable Networks Post Construction + Optimizations For Routing At Scale #29

Open
bonedaddy opened this issue Jan 13, 2020 · 1 comment

Comments

@bonedaddy
Copy link

For internal uses I've done some basic modifications (with the intent on doing some more) that I think would be useful for other users, and might be worth discussing about possible implementation ideas, for which I can provide my modification as the source, or examples to build on.

Currently these are my desired features that I will be implementing in a fork of this that are in a private repository due to dependency issues, and conflicting protocol buffer types, so it's not something that is publicly accessible. If these features are desirable then I'm more than happy to PR them here:

  • being able to manipulate the available routable networks during runtime in a safe, raceless manner
  • Being able to efficiently route between an indeterminate amount of different networks
  • Have the libp2p equivalent of a BGP router for thousands of DHT's with different access requirements while being able to leverage a single shared storage backend to leverage deduplication across networks
  • efficiently+safely routing traffic between IPFS clearnet, and IPFS I2P (ipfs nodes that are both connected to clearnet and i2p, ipfs nodes that are only connected to i2p, bridges to relay traffic between pure i2p ipfs nodes, and clearnet ipfs nodes)

There is probably some aspect to this that might benefit from different perspectives, and perspectives from people who are more familiar with libp2p than my self, so if what I've describe in this sound desirable to others then I think its worth having a discussion about it, and since it's something that I will be doing for myself it could potentially result in less work for libp2p developers to implement the same.

Right now I'm still in the prototype stage of implementing my ideas so I'm just getting started with this. For example this is the current state of tiered.go.

The biggest concern is that this is a breaking change to the way this library is used.

@Stebalien
Copy link
Member

The first router sounds like something that might belong in this repo. Although it's not something go-libp2p/go-ipfs really needs at the moment (we're using these helpers to statically compose a routing stack).

The rest sound interesting but likely out of scope for this repo. Routers in this repo are mean to be simple and composable. Types of routers that might fit include:

  • Delays
  • Caching
  • Async/background publishing
  • Backoff/retry

etc...

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

2 participants