How to read received data in the sample example on QUIC_STREAM_EVENT_RECEIVE event

[chemsallioua]

I am very very new to this library and my question might sound very stupid:

Regarding the sample example provided by this library, after receiving data over a stream, the QUIC_STREAM_EVENT_RECEIVE event is triggered in the ServerStreamCallback (precisely here)

    case QUIC_STREAM_EVENT_RECEIVE:
        //
        // Data was received from the peer on the stream.
        //
        printf("[strm][%p] Data received\n", Stream);
        break;

my question is:

How to read the received data, where is the reference to the buffer where I can find the received data?

Thank you!

[nibanks]

You need to look at the QUIC_STREAM_EVENT* Event payload:

typedef struct QUIC_STREAM_EVENT {
    QUIC_STREAM_EVENT_TYPE Type;
...
        struct {
            /* in */    uint64_t AbsoluteOffset;
            /* inout */ uint64_t TotalBufferLength;
            _Field_size_(BufferCount)
            /* in */    const QUIC_BUFFER* Buffers;
            _Field_range_(0, UINT32_MAX)
            /* in */    uint32_t BufferCount;
            /* in */    QUIC_RECEIVE_FLAGS Flags;
        } RECEIVE;

You'll notice RECEIVE has a several different fields to use. Generally, Buffers and BufferCount will help you get to the actual data.

[chemsallioua]

Thank you!

[Streamlet]

Will one StreamSend on the client side triggers multiple QUIC_STREAM_EVENT_RECEIVE events on the server side?

Can we assume the QUIC_STREAM_EVENT.REVCEIVE.TotalBufferLength always indicates the total length of one StreamSend on the client side?

[Streamlet]

If two sends would be combined and re-splitted into three receives, the sencond of which contains data from the end of the first send and the beginning of the second send?

SEND: AAAAAA BBBBBB
RECV: AAAA AABB BBBB

or

SEND: AAAA BBBB CCCC
RECV: AAAABB BBCCCC

[nibanks]

For a single stream, there are no boundaries enforced/indicated by the QUIC protocol. You would have to add your own. The other option is to use a different stream for each JSON. Then, you'd know it was done because the stream was FIN'ed.

[Streamlet]

Is there extra costs to use different streams than using only one stream?
Is it recommended to use different streams, or a single stream?
What does 'stream' designed for? Is it designed for such cases?
If we use signle stream, and add boundary mechanism, is it means that, we just developed another 'stream', but dropped the original 'stream'?

[nibanks]

A stream is designed to be very low cost and versatile. You can use it for whatever you want. Our 'request per second' perf testing puts each new request in a separate stream (with the response sent on the same stream in the opposite direction). It is very performant.

If each message you send is generally independent, I highly recommend you using separate streams, as putting them on the same stream will make them implicitly dependent, and give you 'head of line blocking'.

[Streamlet]

Thank you very much for your answer!

[Streamlet]

Will QUIC_STREAM_EVENT_RECEIVE events of the same hStream be deliveried on different quic working threads?
If it will, how to identify the order of them?

[nibanks]

All processing, and therefore all events, for a connection and all its streams are done serially, and in order. For a single stream, data is always received in order.

[Streamlet]

Is that means:

1. (msquic library) An hConnection is binded with a workding thread, on which callbacks is executed?

2. (quic protocol) If endpoint starts stream A first, and then starts stream B, does the peer start receiving stream A first, and then start receiving stream B?

3. (quic protocol) If endpoint ends stream A first, and then ends starts B, does the peer receive FIN of stream A first, and then recieve FIN of stream B?

4. (quic protocol) If 2,3 is Yes, is it guaranteed that, every data packet, belonging to the same stream or different streams, is received exactly in the order of how they are sent?

[nibanks]

1. A connection can move between threads, but it never delivers callbacks in parallel on two threads.
2. Streams are independent. They can come out of order, especially if there is packet loss.
3. Same as (2). They are independent and order can change.
4. Data on a single stream is always received in order. Data across different streams are independent of each other and may come in any order.

[Streamlet]

[nibanks]

Please open a separate GitHub issue for this ask. It's hard to track when multiple asks are all on one discussion.

[Streamlet]

OK

[Streamlet]

#4698