class PacketHeader

Returns whether no field is set.

This is which buffer configuration lifetime this header is referring to.

A packet_index is only really meaningful with respect to a particular

buffer_lifetime_ordinal.

See StreamBufferPartialSettings.buffer_lifetime_ordinal.

For QueueInputPacket(), a server receiving a buffer_lifetime_ordinal that

isn't the current input buffer_lifetime_ordinal will close the channel.

For OnFreeInputPacket() and RecycleOutputPacket(), the receiver (client

or server) must ignore a message with stale buffer_lifetime_ordinal.

This is which buffer configuration lifetime this header is referring to.

A packet_index is only really meaningful with respect to a particular

buffer_lifetime_ordinal.

See StreamBufferPartialSettings.buffer_lifetime_ordinal.

For QueueInputPacket(), a server receiving a buffer_lifetime_ordinal that

isn't the current input buffer_lifetime_ordinal will close the channel.

For OnFreeInputPacket() and RecycleOutputPacket(), the receiver (client

or server) must ignore a message with stale buffer_lifetime_ordinal.

The overall set of packet_index values is densely packed from 0..count-1

for input and output separately. They can be queued in any order.

Both the client and server should validate the packet_index against the

known bound and disconnect if it's out of bounds.

When running in single-buffer mode, the buffer index is always 0.

The packet_index values don't imply anything about order of use of

packets. The client should not expect the ordering to remain the same

over time - the stream processor is free to hold on to an input or

output packet for a while during which other packet_index values may be

used multiple times.

For a given properly-functioning StreamProcessor instance, packet_index

values will be unique among concurrently-outstanding packets. Servers

should validate that a client isn't double-using a packet and clients

should validate as necessary to avoid undefined or unexpected client

behavior.

The overall set of packet_index values is densely packed from 0..count-1

for input and output separately. They can be queued in any order.

Both the client and server should validate the packet_index against the

known bound and disconnect if it's out of bounds.

When running in single-buffer mode, the buffer index is always 0.

The packet_index values don't imply anything about order of use of

packets. The client should not expect the ordering to remain the same

over time - the stream processor is free to hold on to an input or

output packet for a while during which other packet_index values may be

used multiple times.

For a given properly-functioning StreamProcessor instance, packet_index

values will be unique among concurrently-outstanding packets. Servers

should validate that a client isn't double-using a packet and clients

should validate as necessary to avoid undefined or unexpected client

behavior.