Back off socket buffer sizes to the OS limit instead of failing - #13
Merged
Conversation
Ports netcode 71469837 (shipped in C v1.3.5). This port still hard-failed, which is a
real behaviour gap and not a cosmetic divergence: Linux and Windows CLAMP an SO_SNDBUF /
SO_RCVBUF request above the OS limit and return success, but the BSDs REJECT it with
ENOBUFS. OpenBSD's default sb_max is well under the 4 MB requested here, so
`set_send_buffer_size(4MB)?` returned Err and nothing could start at all. That is why
the C change exists.
Semantics ported exactly rather than reinvented: try the requested size, halve on
failure, and give up only once the HALVED size would fall below a 256 KB floor. So the
smallest size ever attempted is the floor itself, and the error surfaced is the one from
the last real attempt. Reduced sizes are logged at info, matching the C log line.
The setter is injected rather than called directly, which is what makes this testable
without a BSD to hand:
- Linux/Windows shape: first attempt succeeds, nothing reduced.
- OpenBSD shape: 4M and 2M rejected, 1M accepted -- halving, not jumping to the floor.
- Hostile shape: everything rejected, error surfaces, AND every attempted size is
>= the floor.
That last assertion is the one worth having. A loop that checked the floor BEFORE halving
would try 128K, 64K and eventually succeed with a uselessly small buffer on a machine
that merely has a low limit -- succeeding wrongly rather than failing, which is worse.
Proven able to fail: lowering the floor by one halving makes it fire with the offending
attempt list.
54 lib tests green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
I pushed without running the project's own formatter and CI caught it -- the same class as building under laxer flags than CI uses, which bit me twice earlier today. The project's lint IS part of the build; running it locally is not optional politeness. fmt --check clean, clippy clean, tests green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ports netcode
71469837(shipped in C v1.3.5). This port still hard-failed, which is a real behaviour gap, not a cosmetic divergence.Linux and Windows clamp an
SO_SNDBUF/SO_RCVBUFrequest above the OS limit and return success. The BSDs reject it withENOBUFS. OpenBSD's defaultsb_maxis well under the 4 MB requested here, soset_send_buffer_size(4MB)?returnedErrand nothing could start at all. That is precisely why the C change exists.Semantics ported, not reinvented
Try the requested size, halve on failure, give up only once the halved size would fall below a 256 KB floor. So the smallest size ever attempted is the floor itself, and the error surfaced is the one from the last real attempt. Reduced sizes log at info, matching the C log line.
Testable without a BSD to hand
The setter is injected rather than called directly, so all three platform shapes are covered:
That last assertion is the one worth having. A loop checking the floor before halving would try 128K, 64K, and eventually succeed with a uselessly small buffer on a machine that merely has a low limit — succeeding wrongly rather than failing, which is the worse outcome.
Proven able to fail: lowering the floor by one halving makes it fire, with the offending attempt list
[4194304, 2097152, 1048576, 524288, 262144, 131072].54 lib tests green.