-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good to me!
Huge +1 for the removal of that creature
Once paritytech/polkadot#788 is in we can start to look at merging this. It still needs a follow-up to enable the new network protocol. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what my review is worth, this looks good to me. Just a small question related to tests:
for _ in 0..200 { // Note: don't make that number too high or the CPU usage will explode. | ||
let msg = (0..10).map(|_| rand::random::<u8>()).collect::<Vec<_>>(); | ||
to_send.push(Message::<Block>::ChainSpecific(msg)); | ||
let req_id = loop { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure I understand this correctly, you have witnessed a u64 collision repeatedly? Even with the birthday attack in mind, that is rather unlikely, no? Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the diagram, this test would fail with a probability of about 1/10^15. So yeah, probably overkill. TBH, I thought that RequestId
was u32
(and I suppose the type may yet change), so it seems safer to protect against that. If you push for it I'll change it.
paritytech/polkadot#788 has been merged into polkadot. Shall we try again to get this merged in substrate, too? |
@gnunicorn We need a non-trivial follow-up or it will break Polkadot master. I'm hoping to do that this week. Regardless, we should merge before feature-freeze. |
Thanks for the update, @rphmeier . One idea behind the freeze is to give us some time to upgrade any dependents accordingly without having many unrelated (API) changes... fixing Polkadot after the freeze/during alpha+beta is totally reasonable. Could someone merge latest master in? |
I don't think merging master is hard, but let me know if I should do it. |
Our rule is usually to have a PR for Polkadot waiting. My TODO list is fairly long before I can get to that. We will probably have to make an exception here, because I'd like to remove NetworkSpecialization for 2.0.
Feel free! Thanks |
Merged master. |
@rphmeier anything else to do here before we can merge into substrate? Re Polkadot: I think we can make an exception for the freeze. |
needs another merge with master... |
OK, shall we merge directly before the freeze? I'd like to minimize breakage in Polkadot as much as possible. |
@rphmeier We can also exclude this PR when backporting to |
icing until the freeze (pun intended) |
Master-merging round 3 done. Not totally sure that CI passes. |
The PR's ready to be merged. Since I haven't really followed the story regarding the Substrate freeze and Polkadot, I will let someone else do it. |
I have a PR in the works which adjusts Polkadot to use this. |
* remove networkspecialization * Fix most of the fallout * get all tests compiling Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
This PR removes the
NetworkSpecialization
from the network service.NetworkSpecialization
was an early attempt at customizing the node's network behavior for Polkadot, but there are now better APIs for doing so (register_notifications_protocol
).Historical notes on backwards compatibility
This PR does not introduce network backwards-incompatibility. Potential network backwards incompatibility has been addressed by this series of issues:
chain_status
parameter: Allow empty NetworkSpecialization handshake polkadot#779chain_status
in the handshake when decoding: deprecate chain_status field of network handshake #4675chain_status
member from the handshake: Remove support of network protocols before 6 #4674Breaking API Changes:
The service API is no longer the same. The
construct_simple_protocol
macrowith_network_protocol
function have been removed. Invocations of the macro and function should be deleted without loss of functionality (except whenNetworkSpecialization
was non-empty - then you need to port to theregister_notifications_protocol
).