Remove NetworkSpecialization
#4665
Conversation
rphmeier
added
A3-in_progress
rphmeier
requested review from
andresilva,
Demi-Marie and
mxinden
as code owners
rphmeier
added
A0-please_review
|
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. |
| 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.
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.
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... |
rphmeier
added
A0-please_review
|
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) |
gnunicorn
added
A3-in_progress
|
Master-merging round 3 done. Not totally sure that CI passes. |
gnunicorn
added
A4-awaitingci
and removed
A0-please_review
|
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
NetworkSpecializationfrom the network service.NetworkSpecializationwas 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_statusparameter: Allow empty NetworkSpecialization handshake polkadot#779chain_statusin the handshake when decoding: deprecate chain_status field of network handshake #4675chain_statusmember from the handshake: Remove support of network protocols before 6 #4674Breaking API Changes:
The service API is no longer the same. The
construct_simple_protocolmacrowith_network_protocolfunction have been removed. Invocations of the macro and function should be deleted without loss of functionality (except whenNetworkSpecializationwas non-empty - then you need to port to theregister_notifications_protocol).