-
Notifications
You must be signed in to change notification settings - Fork 968
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.
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
Mandate flow control in bytes #4353
base: master
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -389,10 +389,15 @@ Peer::sendAuth() | |
ZoneScoped; | ||
StellarMessage msg; | ||
msg.type(AUTH); | ||
if (mAppConnector.getConfig().ENABLE_FLOW_CONTROL_BYTES) | ||
#ifdef BUILD_TESTS | ||
if (!mAppConnector.getOverlayManager() | ||
.isFlowControlBytesDisabledForTesting()) | ||
{ | ||
msg.auth().flags = AUTH_MSG_FLAG_FLOW_CONTROL_BYTES_REQUESTED; | ||
} | ||
#else | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: This
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done! |
||
msg.auth().flags = AUTH_MSG_FLAG_FLOW_CONTROL_BYTES_REQUESTED; | ||
#endif | ||
auto msgPtr = std::make_shared<StellarMessage const>(msg); | ||
sendMessage(msgPtr); | ||
} | ||
|
@@ -1740,15 +1745,17 @@ Peer::recvAuth(StellarMessage const& msg) | |
return; | ||
} | ||
|
||
bool enableBytes = | ||
(mAppConnector.getConfig().OVERLAY_PROTOCOL_VERSION >= | ||
Peer::FIRST_VERSION_SUPPORTING_FLOW_CONTROL_IN_BYTES && | ||
getRemoteOverlayVersion() >= | ||
Peer::FIRST_VERSION_SUPPORTING_FLOW_CONTROL_IN_BYTES); | ||
// NOTE: Once min overlay version is 35 we can remove this check | ||
bool bothWantBytes = | ||
enableBytes && | ||
msg.auth().flags == AUTH_MSG_FLAG_FLOW_CONTROL_BYTES_REQUESTED && | ||
mAppConnector.getConfig().ENABLE_FLOW_CONTROL_BYTES; | ||
msg.auth().flags == AUTH_MSG_FLAG_FLOW_CONTROL_BYTES_REQUESTED; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we change this check to
That way once the minimum protocol version >= 35, we can just stop sending/checking AUTH_MSG_FLAG_FLOW_CONTROL_BYTES_REQUESTED entirely, since the flag would be made redundant. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I think that's a good idea. I made that change. |
||
|
||
#ifdef BUILD_TESTS | ||
if (mAppConnector.getOverlayManager() | ||
.isFlowControlBytesDisabledForTesting()) | ||
{ | ||
bothWantBytes = false; | ||
} | ||
#endif | ||
|
||
std::optional<uint32_t> fcBytes = | ||
bothWantBytes | ||
|
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.
I want to call this out because I'm not sure what our usual policy is around removing config options. I opted to have it ignore the option entirely, but warn or error depending on whether the config option matched the new requirement. Another option would be to fail to start. What approach do we usually take?
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.
I think ignoring is fine here. Unlike the BucketListDB config migrations,
ENABLE_FLOW_CONTROL_BYTES
being silently enabled won't break any operators, so we can just warn for a bit then remove the flag.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.
Sounds good! I left this as-is.
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.
Tbh I doubt anyone would be affected by the removal of this flag, since it's sort of an advanced low-level config. You can probably just remove it without graceful deprecation, but we do need to make sure that our own infra isn't using the flag somewhere (to avoid crashing on startup during the release).