-
Notifications
You must be signed in to change notification settings - Fork 2k
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
gcoap_forward_proxy: send empty ACK when response takes too long #18386
gcoap_forward_proxy: send empty ACK when response takes too long #18386
Conversation
46d9f50
to
8d57ffd
Compare
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.
Looks good, needs a rebase
ad67ddc
to
cf58776
Compare
Rebased and squashed |
Murdock results✔️ PASSED 63c4fe5 gcoap: fix "line is longer than 100 characters" pointed out by Vera++
ArtifactsThis only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now. |
Test fail seems unrelated.. |
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.
Code looks good, I trust your testing.
btw: That test script of yours could also be run by Murdock if you replace netdev_tap
with socket_zep
- see e.g. tests/gcoap_fileserver
Mhhh it somewhat relies on someone™ checking if the proxy actually sent an empty ACK. Since this requires a sniffer i.e. root permissions, I don't think having thing run on Murdock (beyond simply checking forward proxy functionality) for now, does not make sense in the scope of this PR. Off-topic BTW: there are some quality defects with the way you defined the native rules with these kinds of tests, which
See also this discussion: #18722 (comment) |
Co-Authored-By: Martine S. Lenders <m.lenders@fu-berlin.de> Signed-off-by: Martine Lenders <m.lenders@fu-berlin.de>
915684f
to
63c4fe5
Compare
arg, just squash directly
Since with
Maybe |
The problem is not the script, the problem is that the build system is not aware about the
Because that's exactly what this script is doing: test the apps and boards like a user would use them, without any CI sugaring. |
But again: off-topic. |
Huh? I did just that... but I had to pull your suggestions first... Or am I missing a Github feature where you can squash suggestions directly into your own commits? |
Nvm, wrote the comment before you squashed the two fixups |
@maribu @leandrolanzieri is it okay to merge this still? |
Contribution description
This allows a forward proxy to ACK a request early, if the response from upstream takes too long. This is based on the work by @chrysn for https://doi.org/10.1145/3405656.3418718 which is why I gave the main authorship of the commit to him. I merely adopted the state of change to the best practices and changes to
forward_proxy
in current master and optimized theclient_ep_t
to keep the increase in RAM-usage minimal (compared to just plane usinguint8_t
s, I was able to safe 3 bytes per entry, compared to using bitmaps, I was able to safe 16 bytes of ROM with my flag-based approach).Testing procedure
I used a version of my trusty proxy testing script again:
To induce a delayed response from the server, I patched the
examples/gcoap
application:When running with 3 TAP interfaces, the output is as follows
With this PR there will be empty ACKs sent by both the proxy and the client (the latter sends it in response to the CON response by the proxy):
On master, there are no empty ACKs, but retransmissions by both the client and the proxy, even though the request should have reached the proxy already (illustrated by the fact, that in the second run, the proxy sends its retransmission before the client):
Issues/PRs references