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

Make specification of protocol in SyncRequester::send_request explicit #10295

Merged
merged 12 commits into from
Feb 8, 2019

Conversation

elferdo
Copy link
Contributor

@elferdo elferdo commented Feb 4, 2019

The function SyncRequester::send_request has a simple logic to match a given packet_id to its corresponding protocol. The logic does not seem to be robust, though, and expecting clients to provide the protocol themselves is not too much burden. If needed, we can still reimplement the matching logic separately.

As a consequence, SyncIO needs no longer provide send and send_protocol.

Fixes #8605

  explicit when calling "SyncRequester::send_packet".

* Remove "SyncIO::send" and leave only "SyncIO::send_protocol"
@parity-cla-bot
Copy link

It looks like @elferdo hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io

Once you've signed, please reply to this thread with [clabot:check] to prove it.

Many thanks,

Parity Technologies CLA Bot

1 similar comment
@parity-cla-bot
Copy link

It looks like @elferdo hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io

Once you've signed, please reply to this thread with [clabot:check] to prove it.

Many thanks,

Parity Technologies CLA Bot

@elferdo
Copy link
Contributor Author

elferdo commented Feb 4, 2019

[clabot:check]

@parity-cla-bot
Copy link

It looks like @elferdo signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

1 similar comment
@parity-cla-bot
Copy link

It looks like @elferdo signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

Copy link
Collaborator

@tomusdrw tomusdrw left a comment

Choose a reason for hiding this comment

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

Looks good, just one worrisome place.

ethcore/sync/src/chain/propagator.rs Show resolved Hide resolved
use ethcore::client::{BlockChainClient, BlockStatus, BlockId, BlockChainInfo, BlockQueueInfo};
use ethcore::snapshot::{RestorationStatus};
use sync_io::SyncIo;
use super::{WarpSync, SyncConfig};
use block_sync::{BlockDownloader, DownloadAction};
use rand::Rng;
use snapshot::{Snapshot};
use api::{EthProtocolInfo as PeerInfoDigest, WARP_SYNC_PROTOCOL_ID, PriorityTask};
use api::{EthProtocolInfo as PeerInfoDigest, ETH_PROTOCOL, WARP_SYNC_PROTOCOL_ID, PriorityTask};
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should rename WARP_SYNC_PROTOCOL_ID to WARP_SYNC_PROTOCOL (as there are already ETH_PROTOCOL and LIGHT_PROTOCOL)

@elferdo
Copy link
Contributor Author

elferdo commented Feb 6, 2019

Any thoughts how to proceed on this? How can I test that the changes work? I have tried running a node and connecting to just one reserved peer, a parity node, and synchronization seems to proceed fine both with and without warp.

Copy link
Collaborator

@tomusdrw tomusdrw left a comment

Choose a reason for hiding this comment

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

@elferdo I'm pretty sure we won't break anything in this PR. As @grbIzl noticed, the protocol of the network is often overwritten using with_context function - IMHO this seems super confusing, I'd prefer to be explicit and use send_protocol always, alternatively as we spoke in DM we could tangle packet and protocol together (using an enum and trait Packet{ fn id() -> u8, fn protocol() -> T } for instance) to prevent any amibguity.

If the sync works and we pass all the tests I'm ok with this PR (modulo the panic). Maybe @grbIzl can suggest how to test private transaction stuff.

ethcore/sync/src/tests/helpers.rs Show resolved Hide resolved
@5chdn 5chdn added this to the 2.4 milestone Feb 7, 2019
@5chdn 5chdn added A8-looksgood 🦄 Pull request is reviewed well. M4-core ⛓ Core client code / Rust. labels Feb 7, 2019
@tomusdrw
Copy link
Collaborator

tomusdrw commented Feb 8, 2019

@elferdo I just noticed those new commits here, I think it would be better to merge this PR asap and then do any follow up work in susbsequent prs. This one is already reviewed and marked as good.

@elferdo
Copy link
Contributor Author

elferdo commented Feb 8, 2019

@elferdo I'm pretty sure we won't break anything in this PR. As @grbIzl noticed, the protocol of the network is often overwritten using with_context function - IMHO this seems super confusing, I'd prefer to be explicit and use send_protocol always, alternatively as we spoke in DM we could tangle packet and protocol together (using an enum and trait Packet{ fn id() -> u8, fn protocol() -> T } for instance) to prevent any amibguity.

I implemented something like what you propose with trait Packet[...], just in the context of syncing, that means ethcore-devp2p still uses both protocol and packet_id as arguments.

@elferdo
Copy link
Contributor Author

elferdo commented Feb 8, 2019

@elferdo I just noticed those new commits here, I think it would be better to merge this PR asap and then do any follow up work in susbsequent prs. This one is already reviewed and marked as good.

Oh, ok, sorry. Should I revert these commits and open a new PR then?

@tomusdrw
Copy link
Collaborator

tomusdrw commented Feb 8, 2019

Should I revert these commits and open a new PR then?

Yes, if you don't mind. I think that will be better, cause otherwise we may end up with never ending story of commit-review cycle and never get anything merged. And it's going to be harder and harder to keep that PR mergeable to master.

@elferdo
Copy link
Contributor Author

elferdo commented Feb 8, 2019

Sure, that makes sense. I'll revert the last changes.

@grbIzl
Copy link
Collaborator

grbIzl commented Feb 8, 2019

Ok. Let's try to close this one and go further

@elferdo elferdo merged commit 046b8bb into master Feb 8, 2019
@elferdo elferdo deleted the fhc-explicit-protocol-send-request branch February 8, 2019 12:01
ordian added a commit that referenced this pull request Apr 5, 2019
* master:
  no volumes are needed, just run -v volume:/path/in/the/container (#10345)
  Fixed misstype (#10351)
  snap: prefix version and populate candidate channel (#10343)
  Bundle protocol and packet_id together in chain sync (#10315)
  role back docker build image and docker deploy image to ubuntu:xenial based (#10338)
  change docker image based on debian instead of ubuntu due to the chan… (#10336)
  Don't add discovery initiators to the node table (#10305)
  fix(docker): fix not receives SIGINT (#10059)
  snap: official image / test (#10168)
  fix(add helper for timestamp overflows) (#10330)
  Additional error for invalid gas (#10327)
  Revive parity_setMinGasPrice RPC call (#10294)
  Add Statetest support for Constantinople Fix (#10323)
  fix(parity-clib): grumbles that were not addressed in #9920 (#10154)
  fix(light-rpc): Make `light_sync` generic (#10238)
  fix publish job (#10317)
  Secure WS-RPC: grant access to all apis (#10246)
  Make specification of protocol in SyncRequester::send_request explicit (#10295)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A8-looksgood 🦄 Pull request is reviewed well. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants