When lsquic serves as the server and handles chromium's(client) ietf quic v1 requests, we encountered a problem.
The error log from client-side is as follows:
I chromium: [918:1415:1119/151718.781863:INFO:quic_connection.cc(2153)] Client: Received Transport ConnectionClose for connection: 7330ae0c3284cfd2, with error: QUIC_IETF_GQUIC_ERROR_MISSING (received MAX_STREAM_DATA frame on never-opened stream 0), transport error code: STREAM_STATE_ERROR, error frame type: 0
It seems lsquic close the connection, as stream 0 was not opened, but the MAX_STREAM_DATA frame arrived first.
Following is the code:
When we captured the packet, we saw that the MAX_STREAM_DATA frame encoded before the request for stream 0
It seems normal.
My question:
But, when I read the RFC 9000, it writes:
So, I think when checking whether the stream is already opened at the point receiving the MAX_STREAM_DATA frame, the lsquic need to check if the stream belong to its side first?
We can discuss more about this.
Wait for your reply.
Lingtaonju
commented
14 hours ago
Dear all:
The story begins here:
When lsquic serves as the server and handles chromium's(client) ietf quic v1 requests, we encountered a problem. The error log from client-side is as follows:
It seems lsquic close the connection, as stream 0 was not opened, but the MAX_STREAM_DATA frame arrived first. Following is the code:
When we captured the packet, we saw that the MAX_STREAM_DATA frame encoded before the request for stream 0
It seems normal.
My question:
But, when I read the RFC 9000, it writes:
So, I think when checking whether the stream is already opened at the point receiving the MAX_STREAM_DATA frame, the lsquic need to check if the stream belong to its side first? We can discuss more about this. Wait for your reply.
Yours sincerely Michel Kong