Repository navigation
Conversation
The combined admission-budget documentation dropped the still-applicable acceptance of nonzero limits and clamping to SIZE_MAX. Restore those rules and explain why an excessively large limit weakens the resource bound. Describe admission without assuming address validation or promising that a waiting peer will necessarily be admitted. Describe the connection limit as an admission limit rather than a bound "at any one time": lowering it does not evict existing connections. Document the internal 128-datagram receive-queue limit, including for accepted connections. Retain the receive-memory scaling explanation, but tie each buffer's minimum size to the datagram-size limit at receipt: previously queued buffers may be smaller after a raise, and reused buffers may stay larger after a reduction. Replace the claim that overflow leaves the connection unaffected with its possible handshake and application-data consequences, and reflow the wording noted during review. Follow-up to openssl#33197 Complements: 8a57e59 "DTLS listener: bound the per-connection receive queue" Complements: 8628bb9 "DTLS listener: make max_pending_conns a combined admission budget" Assisted-by: Codex:gpt-6-astra
The no-validation admission test drives three clients for a fixed number of iterations, then allows about 400 ms for another client to retry after draining it. A slower first phase can advance the refused clients' retransmission backoff beyond that refill window, causing a failure with a working listener. Reuse the existing two-client admission test for NO_VALIDATE. One client fills the queue; the other must send another ClientHello and have datagrams received while full before the test drains the queue. Drive the waiting client through admission and a complete handshake after the drain. Run both validation modes with DTLS 1.2 and 1.3, and update the test-registration comment accordingly. This also removes the duplicated loops whose missing braces were noted in review. Observe successful receives from the second client's loopback port so that outgoing-message callbacks alone cannot satisfy the refusal phase. Count received datagrams separately from outgoing ClientHellos because a ClientHello can span multiple datagrams. End the phase when both counts reach two, matching the following assertions without waiting for an extra retransmission timeout. Use checked listener ticks and propagate their failures to the tests instead of clearing polling errors and treating them as no progress. Follow-up to openssl#33197 Complements: 8628bb9 "DTLS listener: make max_pending_conns a combined admission budget" Complements: 497bdda "DTLS listener: bound the demux free list" Assisted-by: Codex:gpt-6-astra
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
1 participant
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.
I'm addressing the remaining comments on #33197 in a separate PR, as @esyr requested.
The test with address validation disabled gives the clients roughly 400 ms to retry after the queue is drained. If the earlier phase runs slowly, their retransmission backoff can grow past that window and the test fails even though the listener is working.
I have reused the existing test with two clients. One fills the queue, then the other tries to connect while it's full. After draining the queue, the test waits for the second client to be admitted and finish its handshake. Both validation modes now run with DTLS 1.2 and 1.3.
The test checks that the listener receives datagrams from the waiting client, and errors from the listener tick fail the test. Outgoing ClientHellos and received datagrams are counted separately because a ClientHello can be fragmented. Once both counters reach two, there's no need to wait for another retransmission.
Both manuals now describe the connection limit as an admission limit, since lowering it doesn't evict existing connections. The buffer description keeps the explanation of memory use and ties the minimum allocation to the limit in effect when a datagram arrived.
SSL_new_listenerdocuments the internal limit of 128 datagrams, including for accepted connections.SIZE_MAX. The docs again advise against excessively large limits, and the commit message explains the other wording changes.forbodiesChecklist