Cannot receive message in stream_callback on server

[lauix]

Describe the bug

client send a query request to server. when server received the request in the stream_callback function(event is QUIC_STREAM_EVENT_RECEIVE) , I used StreamSend function to send the response data to the client in the stream_callback function, and then the server-side donnot receive any requests.

Affected OS

• [ ] Windows
• [X] Linux
• [ ] macOS
• [ ] Other (specify below)

Additional OS information

No response

MsQuic version

main

Steps taken to reproduce bug

QUIC_STATUS msquic_stream_callback(HQUIC strm, void *context, QUIC_STREAM_EVENT *event) { QUIC_STATUS status = QUIC_STATUS_SUCCESS;

sample_comm_msquic_context *ctx = (sample_comm_msquic_context *)context;
sample_comm_msquic_share_info *msquic_share_info = (sample_comm_msquic_share_info *)ctx->user_data;

switch (event->Type) {
case QUIC_STREAM_EVENT_SEND_COMPLETE: {
    free(event->SEND_COMPLETE.ClientContext);
} break;
case QUIC_STREAM_EVENT_RECEIVE: {

     // build response data

     if (QUIC_FAILED(status = msquic_share_info->msquic_handle->api->StreamSend(strm, send_Buffer, 1, QUIC_SEND_FLAG_ALLOW_0_RTT, send_Buffer))) {
                sample_print("StreamSend failed, 0x%x!\n", status);
                free(send_buffer_raw);
      }
} break;

Expected behavior

can send data in stream_callback function on server-side

Actual outcome

none

Additional details

No response

[nibanks]

Expected Behavior

can send data in stream_callback function on server-side

You absolutely can send in any callback. I suggest you grab logs to diagnose what's going on here. Please see https://github.com/microsoft/msquic/blob/main/docs/Diagnostics.md#trace-collection for more details.

[JyothiAswath]

I am also facing the same issue, is there any setting on the receiver which allows the response to be received inline when the data is sent in the stream_callback function on the server-side. However, I notice when I put a lot of data through a loop by sending multiple streamsend calls in the stream_callback function on the server-side, the data is received immediately back on the client.

[nibanks]

is there any setting on the receiver which allows the response to be received inline when the data is sent in the stream_callback function on the server-side

'inline' to what? The peer's send thread/call? Each connection is separate and not necessarily processed on the same thread.

[JyothiAswath]

Yes, The peer( Server) is sending the RESP via MsQuic->StreamSend to the client during the event QUIC_STREAM_EVENT_RECEIVE within ServerStreamCallback. Whereas in the client, the event QUIC_STREAM_EVENT_RECEIVE within ClientStreamCallback is not triggered, hence the RESP is not received.

However, I modified the code to send the RESP from Server within the ServerStreamCallback in a loop about 1000 times, I could see QUIC_STREAM_EVENT_RECEIVE event triggerd twice in the ClientStreamCallback.

[nibanks]

You'll need to grab logs to diagnose further.

[JyothiAswath]

After enabling the logs, here is my observation. When the RESP is not reaching the ClientStreamCallback , I see that QUIC_STREAM_EVENT_IDEAL_SEND_BUFFER_SIZE event is triggered. When the RESP is reaching the ClientStreamCallback, the expected event ( QUIC_STREAM_EVENT_RECEIVE ) is triggered and not the QUIC_STREAM_EVENT_IDEAL_SEND_BUFFER_SIZE

[JyothiAswath]

is it normal that QUIC_STREAM_EVENT_RECEIVE is not triggered when QUIC_STREAM_EVENT_IDEAL_SEND_BUFFER_SIZE is not triggered? How are we suppose to handle in such a scenario.

[nibanks]

These two events are independent. QUIC_STREAM_EVENT_IDEAL_SEND_BUFFER_SIZE is about how much you should keep queued on the send side to have the best throughput. QUIC_STREAM_EVENT_RECEIVE is when you receive information on a stream.

In general, if you are calling StreamSend on one side, but not getting the QUIC_STREAM_EVENT_RECEIVE event on the other, it means the data you tried to send is getting blocked, likely on flow control. So either you haven't configuring the receiver to allow enough streams, or your receiver isn't draining the previous data it has.