Packet fragmentation

[Beatle95]

Hello. As I saw in some other questions: it is normal for packets to be concatenated while sending. But is it possible to receive not full packet in stream callback (on RECEIVE event)?
Let's say I am prepanding each packet with its length (let's call it app defined length). Is it possible to get receive event on the receiver side, where packet "app defined lengnth" will be 100 bytes, but actual size of the packet will be 50 bytes? Which will mean that the end of the packet will be received in the next receive event.

[nibanks]

But is it possible to receive not full packet in stream callback (on RECEIVE event)?

I am assuming you mean a "send buffer or call" you pass to StreamSend when you say "packet" above. Send calls on the stream are buffers of streamed data. They are not atomic units of data sent as one. If you make a send call with 100 bytes in one buffer, it's entirely possible that gets fragmented into multiple QUIC packets, which are in turn received individually and then possibly delivered to the app individually.

Based on what it sounds like you're doing, another option might be to use a completely separate stream for each "app packet". Streams in QUIC are very light weight. With a single StreamSend API call, you can start the stream, send the complete data, and gracefully shutdown (FIN) the stream. You wouldn't need to encode your own length in the data any longer because the stream would handle that itself. Then, on the receiver side, you simply wait for all the data for that stream to know when you have the full "app packet".