Description
The Transmit struct accepts a single buffer. If it accepted a &[IoSlice]
then I could perform vectored writes.
My use case is actually for WebRTC. I want to batch/encode RTP packets but they have a variable header size due to extensions. I can only add up to 255 bytes of padding for each RTP packet so there's a real limit to what can be batched.
Currently, I have two passes:
- Encode each header to a temporary buffer to learn the size.
- Figure out the next N packets that can be batched.
header.size + payload.size
has to be within 255 bytes.
- Encode the next N packets.
- Copy the header from the temporary buffer.
- Encode the payload.
- Encode padding to equal the segment size.
- Encrypt.
- Send the next N packets in one buffer.
If we supported vectored writes, I think this could be simplified to:
- Encode each packet to its own buffer.
- Figure out the next N packets that can be batched.
buffer.size
has to be within 255 bytes
- Encode the next N packets
- Encode padding to equal the segment size.
- Encrypt.
- Send the next N packets via vectored IO.
The headers aren't huge but it's nice to avoid a copy and additional logic to compute the size. I could alternatively add a header_size()
method to compute the header size before encoding, which is what I did with my old QUIC library, but I don't like how the implementations can drift.
Also I know vectored IO works with GSO because I implemented it at my last company. I was using a segment per buffer but that's not explicitly required.