wired_srvboot_acc Struct Reference

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
quic_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).
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 (quic_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.

Detailed Description

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.

Field Documentation

ack_pn

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.

alt_dcid

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).

zerortt_dg

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 (quic_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).

---

The documentation for this struct was generated from the following file:

• app/http3/server/srvboot/srvboot.h