doc: clarify QUIC stream state wording#63660
Conversation
|
Review requested:
|
478cae7 to
a9a4f4e
Compare
a9a4f4e to
6f7ce01
Compare
|
Friendly ping — just checking in on this documentation clarification. Happy to make any changes if needed! |
|
Note that half-open and half-closed generally have different meanings in networking. Half-open is a failure case, implying one side has crashed or broken somehow. Half-closed implies one side was explicitly/intentionally closed, but the other remains open for listening, this exact scenario. |
|
Hi @Qard, thank you for the feedback on the terminology. You make a great point regarding 'half-open' implying a failure state in networking contexts vs 'half-closed' implying intentional closure of one stream direction. I will update the documentation to explicitly use 'half-closed' instead to avoid any ambiguity. |
|
Thanks @Qard. I've aligned the wording on "half-closed" throughout, since that matches the intentional one-direction-closed semantics here (writable side open, readable side not yet closed), rather than "half-open" which would imply a failure/crash on one peer. The current head already reflects this at all four spots in
So there's no separate term left to change. Let me know if you'd prefer I also spell out "readable side open until the peer sends data / writable side open until |
|
It does not appear to have been updated, and also looks like it needs a rebase. |
99aebb5 to
980617d
Compare
|
Thanks for the patience @Qard, and sorry for the earlier confusion — you were right on both counts. The branch had not actually been updated and was stale. I've now force-pushed a rebased, corrected version:
Validation: Let me know if you'd prefer different phrasing for the unidirectional case (a unidirectional send stream only has the one writable direction, so I kept the same "half-closed (writable side open, no FIN sent)" wording for consistency — happy to adjust if you'd rather it read simply "writable side open, no FIN sent"). |
980617d to
bdf316b
Compare
When the `body` option is omitted, no FIN is sent immediately and the writable side remains open, so the stream can still be written later via `stream.setBody()` or the writer. Per reviewer feedback, describe this state as "half-closed" rather than "half-open": in networking "half-open" implies a failure case (one peer crashed or vanished), whereas "half-closed" reflects the intentional one-direction-open semantics here. Update both `createBidirectionalStream()` and `createUnidirectionalStream()` accordingly and explicitly note that no FIN is sent immediately. Fixes: nodejs#63655 Signed-off-by: Eduard Fischer-Szava <fischer_eduard@yahoo.com>
bdf316b to
897d796
Compare
Qard
left a comment
There was a problem hiding this comment.
It's a bit inconsistent with the "outgoing stream" part. The "outgoing" stream is one of the two halves the "half-closed" terminology is referring to, so saying the outgoing stream itself is half-closed feels a bit semantically wrong.
Summary
createBidirectionalStream()without a body as half-open instead of half-closedcreateUnidirectionalStream()bodydoes not send a FIN immediatelyFixes #63655
Validation
node tools/lint-md/lint-md.mjs doc/api/quic.md