- Generated by
1.16.1
|
wired
libc-free QUIC/HTTP3 SDK in C for x86_64-linux
|
One nascent connection's ClientHello reassembly across Initial datagrams: a ClientHello too big for one Initial (a post-quantum hybrid key share pushes it near 1.7KB) arrives as CRYPTO chunks spread over several packets (RFC 9000 19.6), and the server may not build its flight until the whole message is contiguous. More...
#include <srvboot.h>
Data Fields | |
| crecv | cr |
| CRYPTO stream reassembly buffer. | |
| wired_header | hdr |
| the first datagram's header: its DCID is the ODCID the Initial keys derive from (fixed for the whole boot), its SCID the id the server replies to | |
| u64 | largest_pn |
| highest Initial packet number opened so far (the one the boot flight acknowledges, RFC 9000 13.2.1) | |
| int | any |
| 1 once the first datagram bound this accumulator | |
| usz | opened |
| Initial packets successfully opened so far — 0 means nothing authenticated yet and the attempt is abandonable without loss. | |
| u64 | ack_pn |
| Next server Initial packet number for a partial-ClientHello ACK (wired_srvboot_partial_ack). | |
| usz | hrr_off |
| RFC 8446 4.1.4: crypto-stream offset the retried ClientHello2 starts at (= ClientHello1's full length), recorded when the HelloRetryRequest went out; 0 while no HRR was sent. | |
| usz | ini_tx_off |
| RFC 9000 19.6: the server->client Initial crypto stream's next send offset – the HelloRetryRequest's own length once one went out (the post-retry ServerHello continues the same stream, it must not restart at offset 0), 0 otherwise. | |
| u64 | ecn_ect0 |
| RFC 9000 13.4.1: cumulative ECN counts of the datagrams this boot has physically received (wired_srvboot_acc_ecn_note), carried on the accept flight's / HRR's / partial acks' Initial ACK – the peer validates ECN against the FIRST acknowledgment of a packet it ECT-marked, so waiting for the 1-RTT ACK is already too late (ngtcp2 declares the path not capable and stops marking). | |
| u64 | ecn_ect1 |
| Cumulative count of ECT(1)-marked datagrams (see ecn_ect0). | |
| u64 | ecn_ce |
| Cumulative count of CE-marked datagrams (see ecn_ect0). | |
| u8 | alt_dcid [WIRED_MAX_CID_LEN] |
| An additional DCID admitted alongside the bound one (wired_srvboot_acc_allow): the server's own scid, which the client switches to after the first server packet (RFC 9000 7.2). | |
| u8 | alt_dcid_len |
| Length of alt_dcid; 0 while none is allowed. | |
| u8 | zerortt_dg [WIRED_SRVBOOT_ZERORTT_MAX][WIRED_SRVBOOT_ZERORTT_DG_MAX] |
| RFC 9001 4.6.1: 0-RTT datagrams arrive interleaved with the Initials this accumulator is reassembling the ClientHello from, but their own packet-protection keys (sdrv_early_keys) do not exist until the ClientHello is complete and the server has accepted the PSK – so each whole raw 0-RTT datagram is held here verbatim and only opened once wired_srvboot_accept_acc succeeds (RFC 9000 12.2: never split a datagram's own coalesced packets apart, replay each one exactly as received). | |
| usz | zerortt_len [WIRED_SRVBOOT_ZERORTT_MAX] |
| Byte length of each held 0-RTT datagram in zerortt_dg. | |
| usz | zerortt_n |
| Number of 0-RTT datagrams currently held. | |
One nascent connection's ClientHello reassembly across Initial datagrams: a ClientHello too big for one Initial (a post-quantum hybrid key share pushes it near 1.7KB) arrives as CRYPTO chunks spread over several packets (RFC 9000 19.6), and the server may not build its flight until the whole message is contiguous.
| u64 wired_srvboot_acc::ack_pn |
Next server Initial packet number for a partial-ClientHello ACK (wired_srvboot_partial_ack).
Starts at 2: the accept flight's own server Initial is pn 1, and reusing it would make the peer drop the flight as a duplicate.
| u8 wired_srvboot_acc::alt_dcid[WIRED_MAX_CID_LEN] |
An additional DCID admitted alongside the bound one (wired_srvboot_acc_allow): the server's own scid, which the client switches to after the first server packet (RFC 9000 7.2).
The Initial keys stay the bound ODCID's either way (RFC 9001 5.2).
| usz wired_srvboot_acc::hrr_off |
RFC 8446 4.1.4: crypto-stream offset the retried ClientHello2 starts at (= ClientHello1's full length), recorded when the HelloRetryRequest went out; 0 while no HRR was sent.
Doubles as the "HRR sent" flag: the accumulator keeps ClientHello1's bytes (the crypto stream continues) and completeness/extraction switch to the message at this offset.
| u8 wired_srvboot_acc::zerortt_dg[WIRED_SRVBOOT_ZERORTT_MAX][WIRED_SRVBOOT_ZERORTT_DG_MAX] |
RFC 9001 4.6.1: 0-RTT datagrams arrive interleaved with the Initials this accumulator is reassembling the ClientHello from, but their own packet-protection keys (sdrv_early_keys) do not exist until the ClientHello is complete and the server has accepted the PSK – so each whole raw 0-RTT datagram is held here verbatim and only opened once wired_srvboot_accept_acc succeeds (RFC 9000 12.2: never split a datagram's own coalesced packets apart, replay each one exactly as received).
A datagram beyond WIRED_SRVBOOT_ZERORTT_MAX is simply dropped (its stream data is resent by the client's own retransmission once 0-RTT keys never confirm it, or is covered once the client re-sends over 1-RTT).
1.16.1