A question about the way that the client deal with StatelessReset

[张伟杰]

   When the server is closed, the client will receive the RST packet sent by the server to trigger the ProcessIetfDataPacket function in the quic_framer.cc file, and then call the OnAuthenticatedIetfStatelessResetPacket function and return true, so the Process-UdpPacket function in the quic_framer.cc file will continue to call the SetPingAlarm function Set the timing for the connection. Is this a problem? When the client triggers the OnAuthenticatedIetfStatelessResetPacket function, does it mean that the connection should be closed and the timing should not continue to be set.

[Fan Yang]

This is a great question. You are right, ideally, alarms should not be set after the connection gets closed. 

As you observed, the PING alarm can be set after receiving a stateless reset packet. This is a noop since the PING alarm gets permanently cancelled while connection gets closed (but a QUIC_BUG will be triggered).

Thanks for catching this! 

Fan

On Fri, Sep 3, 2021 at 12:15 AM 张伟杰 <zhangw...@gmail.com> wrote:

   When the server is closed, the client will receive the RST packet sent by the server to trigger the ProcessIetfDataPacket function in the quic_framer.cc file, and then call the OnAuthenticatedIetfStatelessResetPacket function and return true, so the Process-UdpPacket function in the quic_framer.cc file will continue to call the SetPingAlarm function Set the timing for the connection. Is this a problem? When the client triggers the OnAuthenticatedIetfStatelessResetPacket function, does it mean that the connection should be closed and the timing should not continue to be set.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/1f97cb66-b834-4951-8967-4ef77c541bbbn%40chromium.org.

[张伟杰]

Thank you for your affirmation. When do you plan to modify this part of the code?

[Fan Yang]

Ideally, there should be a connected check after framer's ProcessPacket (we will add it soon).

Currently, there is a connected check in SetPingAlarm and Ping alarm will be permanently cancelled when connection gets disconnected, so the code should WAI. Out of curiosity, is this causing problems or?

Thank you. Fan

[张伟杰]

I am testing when the server restarts in a short period of time, the compiled debug version will coredump. The reason for coredump is line 129 of the quic_connection.cc file. The code will check whether the connection before the server restarts is still connected, and then cancel the timing.  In the debug version, this line of DCHECK (connection_->connected()) will coredump

[Fan Yang]

Hmmm, that is surprising, can you please print out when the PING alarm gets armed (presumably, after the connection gets disconnected)?

[Seeสมพร Seeพงษ์ทรัพย์สม]

ในวันที่ พฤ. 16 ก.ย. 2021 03:28 น. Fan Yang <fay...@chromium.org> เขียนว่า:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAD_8i%2BQ6tpJ2jszvrE-aSwTVm60zubqEkzL2dndWFjTnHTvthg%40mail.gmail.com.