How to properly close multiple connections (non-timeout mode)?

[muyiwq]

Dear Mr:

quicsample question：

1. When MsQuic->ConnectionClose(Connection) is successfully called; why the connection is still the same address as the original, not nullptr. Almost all handles have this problem, is it designed like this?
2. Single-process multi-client connections exceed 1000, sometimes blocking RegistrationClose().Normal when there are few connections。

Phenomenon

The client and server are disconnected after timeout. I try to call ConnectionClose() while the stream callback QUIC_STREAM_EVENT_SHUTDOWN_COMPLETE. It will enter the connection callback QUIC_CONNECTION_EVENT_SHUTDOWN_COMPLETE again and call ConnectionClose() again,Caused a segfault on 2 shutdowns.
If I no longer call ConnectionClose() in the connection callback, it seems that there is no problem. When I try to run multiple RunClient() in a single process, I find that more than 1000 connections are sometimes closed normally, sometimes blocked RegistrationClose(),Not sure when it will appear, but there is no way to know which handles have not been released
After this transformation, when the server cannot be connected (the server is not started), the client cannot close the connection normally because the connection is not closed.

Performance Dashboard question：
3.Requests per Second：Does it represent the average request capability of multiple connections and multiple streams?
I want to know how many short connections can send a piece of data in about one second?
Looking forward to your suggestion？

[nibanks]

Hello @muyiwq! I've got a few comments in response to your questions:

• ConnectionClose is essentially delete or free so you never want to call that twice on the same connection pointer. Also, once you call it, you should assume the memory has been freed, so you must not call anything else on that (such as GetParam).
• RegistrationClose is designed to block and wait for all existing connections to be closed before it returns. This is a synchronization mechanism used for clean up. If you are seeing this "hang" seemingly indefinitely, then you must have some outstanding connections you haven't closed yet. Grabbing logs can help with this.
• Instead of calling ConnectionClose in the QUIC_STREAM_EVENT_SHUTDOWN_COMPLETE callback, I'd recommend just calling ConnectionShutdown there. That will start the process of informing the peer of the shutdown, and eventually result in the QUIC_CONNECTION_EVENT_SHUTDOWN_COMPLETE event to you. In response to that event, you should then call ConnectionClose (assuming you don't have any other code still referencing the connection).
• For the RPS in our dashboard, this represents the average (over a 10 second period) number of requests we could complete for the given hardware and software configuration. If you could give me a bit more information on exactly the type of scenario you're trying to test, I can let you know if our tests are "close enough" or if more testing would be required.

If I didn't answer all your questions, feel free to follow up with more questions!