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

If I need only an outgoing connection, why libp2p should be start()'ed to listening for incoming connections? #341

Closed
overphoenix opened this issue Mar 20, 2019 · 5 comments
Closed

If I need only an outgoing connection, why libp2p should be start()'ed to listening for incoming connections? #341

overphoenix opened this issue Mar 20, 2019 · 5 comments
Labels
exp/expert Having worked on the specific codebase is important good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/stale need/author-input Needs input from the original author

Comments

@overphoenix
Copy link

I think it is worth reconsidering the need to start the node in the case of client-server scenarios, when one node dials another, but the first one (connection initiator side) does not need to be start()-ed.

For example, I need to connect to a public network from private network or if we have two nodes on the same host - first node as server and second node as client. Current implementation consumes more resources than it needs and in most cases is not secure.

The architecture of the libp2p node should allow to do this, since in a large way this does not contradict anything.

P. S. May be this topic has already been discussed, but I did not see how to get workaround using current js-libp2p implementation.
@overphoenix overphoenix changed the title There is no need to start the node if only an outgoing connection is needed There is no need to start the node if only an outgoing connection Mar 21, 2019
@overphoenix
Copy link
Author

As I understand, no one is particularly in a hurry to discuss this moment ))

Maybe then I should make a pull request with these changes?

@overphoenix overphoenix changed the title There is no need to start the node if only an outgoing connection If I need only an outgoing connection, why libp2p should be start()'ed to listening for incoming connections? Mar 21, 2019
@jacobheun
Copy link
Contributor

I think this is a reasonable thing to allow. The addition of the no dial when offline is quite old, #43. I don't have any context to why it was added. While there are scenarios where applications may want to avoid dialing, this is a reasonable check that can be added to the application (js-ipfs does this).

The stats system in libp2p-switch is an example of something that consumes a lot of resources during startup that likely isn't necessary to run, depending on what you're using it for.

A caveat of this is losing things connection management if you don't start the node, but if you really don't need any of that, a bare bones libp2p implementation shouldn't block you from dialing.

I'm open to a PR for this, it will be a breaking change. @vasco-santos any thoughts?

@jacobheun jacobheun mentioned this issue Apr 3, 2019
Closed
jacobheun pushed a commit to jacobheun/js-libp2p that referenced this issue Aug 8, 2019
@alanshaw @jacobheun
refactor: blacklist to denylist (libp2p#341)
f64c73b 
"denylist" more adequately describes what this list is for.

BREAKING CHANGE: Constructor options `blacklistTTL` and `blackListAttempts` have been renamed to `denyTTL` and `denyAttempts`. The error code from errors thrown when dial is currently denied has changed from `ERR_BLACKLISTED` to `ERR_DENIED`.

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
@snyk-bot snyk-bot mentioned this issue Jan 21, 2022
Open
@snyk-bot snyk-bot mentioned this issue Mar 21, 2022
Open
@achingbrain
Copy link
Member

This is an interesting use case that would open up scenarios like curl or wget on the command line for sending packets of data to peers.

When the node is started lots of things happen like contacting DHT peers or interacting with the datastore (via the peer store, etc) so it may not be possible without some extra overhead.

It's not something the current implementation is designed around but there's no reason it shouldn't be possible if you have a multiaddr to connect to.

To move this forward I would suggest creating a demo app that just uses a minimal set of components to make the connection (the tcp transport for example), this will bottom out what's required to make a connection and we can use that to inform a refactor of the codebase to allow for offline dialing.

@achingbrain achingbrain added exp/expert Having worked on the specific codebase is important good first issue Good issue for new contributors help wanted Seeking public contribution on this issue and removed exploration labels Oct 5, 2022
@maschad maschad added the need/author-input Needs input from the original author label Sep 28, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Oct 5, 2023

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

@github-actions
Copy link
Contributor

This issue was closed because it is missing author input.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
exp/expert Having worked on the specific codebase is important good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/stale need/author-input Needs input from the original author
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jacobheun @achingbrain @maschad @overphoenix