pub struct ServeReport {
pub frames: usize,
pub requests: usize,
pub replies: usize,
}Expand description
The handler’s view of the peer’s id.
A notification has none, and RequestContext insists on one because a
handler may be handed a progress token or a cancellation token and needs
something to correlate against. A notification can be given neither, so
nothing it does can reach the peer and the value is unobservable — it
exists only so the context can be built at all.
The mapping itself is RequestId::from_wire, in the domain, and the
refusal mapping is DispatchError::as_wire, in the application layer:
both are properties of a value rather than of the way this loop writes it
down, and the HTTP router needs them for the same reasons this loop does.
What a finished session did.
Counted, not merely logged, so that “the loop ran once and served nothing” is a number a caller can assert on rather than an absence nobody notices.
Fields§
§frames: usizeFrames read off the peer’s stream, including ones that did not decode.
requests: usizeMessages routed to a handler, including notifications and refusals.
Counts the messages, so a batch of three raises this by three.
replies: usizeDocuments written to the peer’s stream.
Counts the documents, so a batch of three requests raises this by one. The two counts differ by design: they answer different questions, and a report that used one number for both would be answering neither.