Skip to content

[R32] Honor exact configured socket packet limits - #35

Open
JetF0x wants to merge 1 commit into
Carsillas:rewritefrom
JetF0x:fix/review-r32
Open

JetF0x wants to merge 1 commit into
Carsillas:rewritefrom
JetF0x:fix/review-r32

Conversation

@JetF0x

@JetF0x JetF0x commented Sep 12, 2026

Copy link
Copy Markdown

Addresses review finding R32.

SocketTransport configured with maxPacketSize of 1, 2, or 3 currently permits payloads up to four bytes because validation uses the receive buffer's minimum header capacity. Store the configured payload maximum separately and use it for both outgoing message validation and incoming frame lengths. Keep enough buffer capacity for the four-byte header.

Oversized sends throw before writing a frame, and oversized incoming headers disconnect the transport before waiting for a body or delivering a message. The tests cover each small limit, both header-only and complete oversized frames, empty and exact-limit round trips after a rejected send, and four/eight-byte limit controls. The public constructor still accepts a uint and rejects zero and values above int.MaxValue; the framing format is unchanged.

Validation on Windows with .NET SDK 10.0.400 and the .NET 8 runtime:

  • Red: adding the tests to unchanged production source at 37f4e1ffb1d7fc3e7bcdea3dfbbd4484f9fe7516 produced 9 failures and 12 passes in the focused transport suite. The failures independently reproduce outgoing acceptance, incoming delivery, and waiting for bodies after oversized headers at limits 1–3.
  • Green: all 21 SocketTransportTests cases pass, including constructor controls for zero, int.MaxValue + 1, and uint.MaxValue.
  • The complete runtime test project passes: 171/171 tests. The existing MemoryRelayTransport.cs:21 CS8600 warning remains. The separate analyzer/generator test projects were not rerun for this runtime-only change.
  • git diff --check passes. Linux socket behavior and allocation of near-int.MaxValue buffers were not exercised.

This PR is based directly on rewrite at 37f4e1ffb1d7fc3e7bcdea3dfbbd4484f9fe7516 and covers R32. R1 / PR #5 separately changes the receive loop to read incrementally and detect EOF. When combining the changes, retain this PR's configured MaxPacketSize and use packetSize > MaxPacketSize in R1's updated receive loop after the complete header is decoded. R1's EOF and large-frame progress behavior is not implemented by this PR; the combined branch has not been tested here and should run both transport regression sets.

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.

1 participant