Proper way to use immediate data transmission for streams: Waiting in picoquic_prepare_to_send needed? How immediate is immediate?

[Mike-RandoNumber]

There is a commonly used caveat not to sit in callbacks, while I do not get the full picture for the picoquic_prepare_to_send callback (likely also its datagram counterpart). The buffer and length variables appear only in the callback context. Is the preferred pattern to perform a "wait for data" here or to decouple this via storing the pointers/value of buffer and length into a queue (which raises other questions in terms of concurrency).?

[huitema]

You certainly do not want to "wait for data" -- that would be exactly the "sit on the callback" issue. The application should only mark the stream as "ready" if it can immediately send data. Depending on the application, that could be different things. A 'sensor" application might want to just get the state of the sensor. A video conference application might mark the stream ready when a video frame has been prepared, and then send the bytes of the frame in response to the "prepare to send" callback. It might fragment the data and send them in response to several successive callbacks.

[Mike-RandoNumber]

Given that the data have a scattered temporal behaviour, the application may encounter a period, where there is kind of data starvation and on the other extreme back to back data - what would be kind of a pseudo code decoupling? I checked the examples not yet the full test sw for inspiration.
Is a stream the best approach? Or better move into datagrams?

[huitema]

There are several solutions, based on whether the application data should delivered in sequence or not, and whether losses are acceptable:

• if complete sequencing is required and no losses are acceptable: everything should be on a single stream. Downside: head of line blocking.
• if partial sequencing is sufficient and no losses are acceptable: one stream per logical sequence. Example: for a web page with multiple components, HTTP3 will use one stream per component. Downside: a bit more complexity, packet losses would only block one stream, reducing head of line blocking effect.
• if losses are acceptable an application data units are short (e.g., under 1KB), you can use datagrams. Example: audio stream in a teleconference, short packets sent every 20ms, media rendering includes loss concealment. Advantage: no head of line blocking.

The extreme variant of partial sequencing would be "one stream per message", as in DNS over QUIC: open on bidir stream per transaction, client send the query on the stream, server sends the response on the other direction of the stream.