tquic close的时序问题

[stopandjoin]

发现一个现象：
tquic的 server端与 client端正常连接与交互数据， 然后client端调用quic_conn_close 关闭连接， server端正常回调了server_on_conn_closed。 然后较短时间内（3s 内），client再次连接， server端在没有回调前期的create，established 等初始回调时，直接就回调了 stream readable了，会导致crash。
这里有个疑问是，在server端回调server_on_conn_closed后，需要对connection做什么清理工作吗，以便继续监听下一个connection 。

[glime-ai[bot]]

在您描述的情况中，当客户端调用 quic_conn_close 关闭连接后，服务端确实会收到 on_conn_closed 的回调。根据您提供的信息，on_conn_closed 回调函数中适合进行连接相关的清理工作，以确保连接的资源被适当释放，并准备好接受新的连接。

在 on_conn_closed 回调执行后，您应该确保：

1. 清理与该连接相关的所有资源，包括与连接相关的任何动态分配的内存。
2. 如果您维护了关于活动连接的列表或其他数据结构，确保从中移除已关闭的连接。
3. 重置或重新初始化与连接相关的任何状态变量，以便服务器准备好接受新的连接。

此外，确保服务器端的监听套接字（如果有的话）仍然处于监听状态，以便继续接受新的连接请求。

如果在短时间内重复连接导致崩溃，可能是因为连接关闭后某些资源未被正确清理或重置。建议检查 on_conn_closed 中的处理逻辑，确保所有资源都得到了妥善处理。

如果问题仍然存在，可能需要进一步检查代码逻辑，或者考虑是否有必要在服务器端实现逻辑以处理快速重连的情况，例如通过设置适当的超时或检查旧连接的状态。

This comment was generated by Glime.

[stopandjoin]

@iyangsj 是的，最开始的log过滤了。 我又抓了一份全log，如下：
1.log

[iyangsj]

使用如下命令过滤日志：

egrep "server_on_conn_created|server_on_conn_established|server_on_stream_readable" 1.log

结果见附件，所有连接的readable回调都与对应_established日志配对且在其后。日志中没有你描述的现象。
readable.txt

另外，建议连接ID使用quic_conn_trace_id, 而不是内存指针地址。后者可能会随着内存释放和分配出现重复，影响分析。
https://tquic.net/docs/api_reference/c_quic/#quic_conn_trace_id

[stopandjoin]

好的，谢谢。 我大概知道什么原因了，就是client关闭连接后，马上再重连， server端认为是新来了一个connection，所以会创建很多个connection， 过一段时间后这些连接会批量的回调conn_close ，如下：

像这种情况，server端可以通过什么方式把这些连接判定是同一个（来自同一个endpoint）连接？ @iyangsj

[iyangsj]

tquic server默认通过CID来区分连接，tquic server不关心不同连接是否来自同一个client endpoint（应用程序可在应用层标识来自同一用户的访问）