Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Be able to run full and light client simultaneously (with portshift) #8927

Closed
Tbaut opened this issue Jun 19, 2018 · 14 comments
Closed

Be able to run full and light client simultaneously (with portshift) #8927

Tbaut opened this issue Jun 19, 2018 · 14 comments
Labels
F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. M4-core ⛓ Core client code / Rust. P9-somedaymaybe 🌞 Issue might be worth doing eventually. Q3-medium A fair chunk of work, not necessarily very hard but not trivial either
Milestone
2.1 Whatever

Comments

@Tbaut
Copy link
Contributor

Tbaut commented Jun 19, 2018 •
edited
Loading

As the title says, we should be able to run both clients on the same machine as long as there is a port-shift:

$ parity --light # Run light client
$ parity --ports-shift 100 # Run full client with ports-shift

Light and full clients should use separated directories, the keys should be shared.
A particular attention should be paid to the directory code as it varies between platforms. Proper tests should be performed.
@Tbaut Tbaut added P5-sometimesoon 🌲 Issue is worth doing soon. F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. M4-core ⛓ Core client code / Rust. labels Jun 19, 2018
@Tbaut Tbaut added this to the 1.12 milestone Jun 19, 2018
@Tbaut Tbaut added Q3-medium A fair chunk of work, not necessarily very hard but not trivial either and removed P5-sometimesoon 🌲 Issue is worth doing soon. Q3-medium A fair chunk of work, not necessarily very hard but not trivial either labels Jun 19, 2018
@Tbaut

This comment has been minimized.

Sign in to view
@Tbaut Tbaut closed this as completed Jun 19, 2018
@Tbaut

This comment has been minimized.

Sign in to view
@Tbaut Tbaut reopened this Jun 20, 2018
@Tbaut Tbaut changed the title Avoid "light" and "full" client to delete each other's db when doing "db kill" Be able to run full and light client simultaneously (with portshift) Jun 20, 2018
@Tbaut Tbaut added P5-sometimesoon 🌲 Issue is worth doing soon. Q3-medium A fair chunk of work, not necessarily very hard but not trivial either labels Jun 20, 2018
@5chdn
Copy link
Contributor

5chdn commented Jun 20, 2018

I don't see why this is relevant. It has never been possible to run two instances with the same data directory.

@5chdn 5chdn closed this as completed Jun 20, 2018
@tomusdrw
Copy link
Collaborator

You can run different chains and different pruning algos without changing any other settings, imho it makes sense to have similar behaviour for different modes (like --light). It will make the transition smoother IMHO (you can share the same keys without extra configuration)

@5chdn 5chdn reopened this Jun 20, 2018
@5chdn
Copy link
Contributor

5chdn commented Jun 20, 2018

But that's already possible with --db-path ?!? I don't see why we should waste resources on something that's already possible.

@5chdn 5chdn added P9-somedaymaybe 🌞 Issue might be worth doing eventually. and removed P5-sometimesoon 🌲 Issue is worth doing soon. Q3-medium A fair chunk of work, not necessarily very hard but not trivial either labels Jun 20, 2018
@5chdn 5chdn modified the milestones: 1.12, 1.14 & ... Jun 20, 2018
@roninkaizen
Copy link

works fine with 2 different config.toml files since version 1.9.x-
always tested with at least one node-
some examples within the wiki would be nice, to make the user aware of the
exact handling while using parity db kill in such constellations

@5chdn 5chdn added the Q3-medium A fair chunk of work, not necessarily very hard but not trivial either label Jun 24, 2018
mttmartin added a commit to mttmartin/parity that referenced this issue Jul 5, 2018
@mttmartin
Add seperate default DB path for light client (openethereum#8927)
21c290f
@mttmartin
Copy link
Contributor

@Tbaut, should all directories be separate(except keys) or just the chains directory?

@Tbaut
Copy link
Contributor Author

Tbaut commented Jul 6, 2018

The keys and db are the 2 directories that matter. keys can prob. be shares (didn't try it) the db should not.

@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 0.7 ETH (320.84 USD @ $458.35/ETH) attached to it.

@gitcoinbot
Copy link

gitcoinbot commented Jul 10, 2018 •
edited
Loading

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work has been started.

These users each claimed they can complete the work by 7 months ago.
Please review their action plans below:

1) mttmartin has started work.

I'm working on this.

Learn more on the Gitcoin Issue Details page.

@Tbaut
Copy link
Contributor Author

Tbaut commented Jul 10, 2018 •
edited
Loading

#9064

@Tbaut
Copy link
Contributor Author

Tbaut commented Jul 10, 2018

edit: all good @mttmartin, that's your PR :)

mttmartin added a commit to mttmartin/parity that referenced this issue Jul 11, 2018
@mttmartin
Add seperate default DB path for light client (openethereum#8927)
b6b8f69
5chdn pushed a commit that referenced this issue Jul 11, 2018
@mttmartin @5chdn
Add separate database directory for light client (#8927) (#9064)
796637b 
* Add seperate default DB path for light client (#8927)

* Improve readability
@5chdn 5chdn closed this as completed Jul 11, 2018
@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work for 0.7 ETH (311.48 USD @ $444.97/ETH) has been submitted by:

  1. @mttmartin

@vs77bb please take a look at the submitted work:

5chdn pushed a commit that referenced this issue Jul 12, 2018
@mttmartin @5chdn
Add separate database directory for light client (#8927) (#9064)
3f53e0e 
* Add seperate default DB path for light client (#8927)

* Improve readability
5chdn added a commit that referenced this issue Jul 17, 2018
@5chdn
Backports to 2.0.0-beta (#9094)
6eae372 
* parity-version: betalize 2.0

* Multiple improvements to discovery ping handling (#8771)

* discovery: Only add nodes to routing table after receiving pong.

Previously the discovery algorithm would add nodes to the routing table
before confirming that the endpoint is participating in the protocol. This
now tracks in-flight pings and adds to the routing table only after receiving
a response.

* discovery: Refactor packet creation into its own function.

This function is useful inside unit tests.

* discovery: Additional testing for new add_node behavior.

* discovery: Track expiration of pings to non-yet-in-bucket nodes.

Now that we may ping nodes before adding to a k-bucket, the timeout tracking
must be separate from BucketEntry.

* discovery: Verify echo hash on pong packets.

Stores packet hash with in-flight requests and matches with pong response.

* discovery: Track timeouts on FIND_NODE requests.

* discovery: Retry failed pings with exponential backoff.

UDP packets may get dropped, so instead of immediately booting nodes that fail
to respond to a ping, retry 4 times with exponential backoff.

* !fixup Use slice instead of Vec for request_backoff.

* Add separate database directory for light client (#8927) (#9064)

* Add seperate default DB path for light client (#8927)

* Improve readability

* Revert "Replace `std::env::home_dir` with `dirs::home_dir` (#9077)" (#9097)

* Revert "Replace `std::env::home_dir` with `dirs::home_dir` (#9077)"

This reverts commit 7e77932.

* Restore some of the changes

* Update parity-common

* Offload cull to IoWorker. (#9099)

* Fix work-notify. (#9104)

* Update hidapi, fixes #7542 (#9108)

* docker: add cmake dependency (#9111)

* Update light client hardcoded headers (#9098)

* Insert Kovan hardcoded headers until #7690241

* Insert Kovan hardcoded headers until block 7690241

* Insert Ropsten hardcoded headers until #3612673

* Insert Mainnet hardcoded headers until block 5941249

* Make sure to produce full blocks. (#9115)

* Insert ETC (classic) hardcoded headers until block #6170625 (#9121)

* fix verification in ethcore-sync collect_blocks (#9135)

* Completely remove all dapps struct from rpc (#9107)

* Completely remove all dapps struct from rpc

* Remove unused pub use

* `evm bench` fix broken dependencies (#9134)

* `evm bench` use valid dependencies

Benchmarks of the `evm` used stale versions of a couple a crates that
this commit fixes!

* fix warnings

* Update snapcraft.yaml (#9132)
@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

The funding of 0.7 ETH (327.21 USD @ $467.44/ETH) attached to this issue has been approved & issued to @mttmartin.

@5chdn 5chdn modified the milestones: 2.2, 2.1 Jul 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. M4-core ⛓ Core client code / Rust. P9-somedaymaybe 🌞 Issue might be worth doing eventually. Q3-medium A fair chunk of work, not necessarily very hard but not trivial either
Projects
None yet
Milestone
2.1 Whatever
Development

No branches or pull requests
6 participants
@tomusdrw @mttmartin @5chdn @roninkaizen @gitcoinbot @Tbaut