Skip to content
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

Add method to RelayFrame to reveal Arg2 offset #746

Merged
merged 7 commits into from
Jul 31, 2019

Conversation

devastating
Copy link
Contributor

Add a method "Arg2EndOffset" to RelayFrame interface so that we could
know how much space Arg2 is used. This is the first step to know if it's
possible to add more methods in Relay code to allow Relayer to inject
more headers or read the headers to decide which peer to forward to.

NOTE: this is a breaking change to RelayFrame interface.

Related to #745. Will use this change to know Arg2 usage.

Add a method "Arg2EndOffset" to RelayFrame interface so that we could
know how much space Arg2 is used. This is the first step to know if it's
possible to add more methods in Relay code to allow Relayer to inject
more headers or read the headers to decide which peer to forward to.

NOTE: this is a breaking change to RelayFrame interface.

Related to uber#745. Will use this change to know Arg2 usage.
@CLAassistant
Copy link

CLAassistant commented Jul 27, 2019

CLA assistant check
All committers have signed the CLA.

@codecov
Copy link

codecov bot commented Jul 27, 2019

Codecov Report

Merging #746 into dev will increase coverage by 0.24%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##              dev     #746      +/-   ##
==========================================
+ Coverage   88.14%   88.39%   +0.24%     
==========================================
  Files          40       40              
  Lines        4058     4066       +8     
==========================================
+ Hits         3577     3594      +17     
+ Misses        366      360       -6     
+ Partials      115      112       -3
Impacted Files Coverage Δ
relay_messages.go 100% <100%> (ø) ⬆️
connection.go 87.34% <0%> (-1.02%) ⬇️
relay.go 82.87% <0%> (-0.62%) ⬇️
peer.go 93.45% <0%> (-0.37%) ⬇️
outbound.go 90.05% <0%> (ø) ⬆️
preinit_connection.go 94.16% <0%> (+1.45%) ⬆️
inbound.go 81.81% <0%> (+1.6%) ⬆️
mex.go 77.72% <0%> (+5.21%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 95fb962...023b52b. Read the comment docs.

Copy link
Contributor

@prashantv prashantv left a comment

Choose a reason for hiding this comment

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

Add test cases for:

  • 0 length arg2
  • positive length arg2 (with and without overflow to another frame)
  • max length arg2 (with and without overflow to another frame)

We might also want to add arg2 starting offset so we can use [end-start] as an estimate of the header size for metrics (related to T2938739)

relay_messages.go Outdated Show resolved Hide resolved
@devastating
Copy link
Contributor Author

Add test cases for:

* 0 length arg2

* positive length arg2 (with and without overflow to another frame)

* max length arg2 (with and without overflow to another frame)

We might also want to add arg2 starting offset so we can use [end-start] as an estimate of the header size for metrics (related to T2938739)

Not quite sure I understand the difference between positive length and max length, but I've added tests for 0 length arg2 and arg2 which spans across frames.

relay_messages.go Outdated Show resolved Hide resolved
cr.arg2StartOffset = cur + 2
cr.arg2EndOffset = cur + 2 /*arg2 len*/ + int(binary.BigEndian.Uint16(f.Payload[cur:cur+2]))
// arg2 is fragmented if we don't see arg3 in this frame.
cr.isArg2Fragmented = int(cr.Header.FrameSize()) <= (FrameHeaderSize+cr.arg2EndOffset) && f.Payload[_flagsIndex]&hasMoreFragmentsFlag != 0
Copy link
Contributor

Choose a reason for hiding this comment

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

instead of using frame size here, if you use PayloadSize(), then you won't need to add FrameHeaderSize and it'll be a litlte simpler.

similarly, don't access the flags directly, use the method HasMoreFragments()

cr.isArg2Fragmented = int(cr.Header.PayloadSize()) <= cr.arg2EndOffset && cr.HasMoreFragments()

can we add a test for case where a call doesn't set the has more fragments flag, and doesn't have arg3

Copy link
Contributor Author

@devastating devastating Jul 30, 2019

Choose a reason for hiding this comment

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

Good point - I think I made the mistake that the offset is from start of the payload to Arg2, not from the start of frame (which includes header).

Added test for the flag is not set and does not have arg3.

testutils/call.go Outdated Show resolved Hide resolved
@@ -183,6 +193,18 @@ func (f lazyCallReq) HasMoreFragments() bool {
return f.Payload[_flagsIndex]&hasMoreFragmentsFlag != 0
}

// Arg2EndOffset returns the offset from start of payload to the end of Arg2
// in bytes, and whether there are more data from other frames.
Copy link
Contributor

Choose a reason for hiding this comment

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

"more data from other frames" --> let's make this more clear. we only return true here if there's more frames and we haven't yet started arg3, right?

@prashantv
Copy link
Contributor

As discussed offline, let's follow this up with integration tests that use the Arg2Writer to write different values (huge values, forcefully flush, etc) to ensure the returned values match what we expected.

Separately, can you file an issue for ensuring we don't ever "overflow" reads? If we send a corrupt packet, it may cause out-of-bounds access.

@devastating
Copy link
Contributor Author

As discussed offline, let's follow this up with integration tests that use the Arg2Writer to write different values (huge values, forcefully flush, etc) to ensure the returned values match what we expected.

Separately, can you file an issue for ensuring we don't ever "overflow" reads? If we send a corrupt packet, it may cause out-of-bounds access.

Created #747

@devastating devastating merged commit 2ca7c38 into uber:dev Jul 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants