client::init::client::create_read_handler and server::init::server::create_read_handler are responsible for reading data from the connection via UDP. Multiple connections are created on both the server and the client to distribute the load between several asynchronous tasks.
In Client::disconnect and Server::disconnect disconnections, in the case of a GracefullyDisconnection, the same socket is used to send data with the disconnection justification, and the same socket is used to receive confirmation of the disconnection justification.
Although the asynchronous task handler (tasks_keeper_handle) is being discussed, it was possible to notice that the read handler can receive data from the socket, causing the server/client that is disconnecting with justification to not read the justification, and the code only ends when the disconnection timeout occurs.
Suggestion: add flag in tasks_keeper_handler, to instead of cancelling the handler, cancel each pending task.
Robsutar
commented
5 hours ago
client::init::client::create_read_handlerandserver::init::server::create_read_handlerare responsible for reading data from the connection via UDP. Multiple connections are created on both the server and the client to distribute the load between several asynchronous tasks.In Client::disconnect and Server::disconnect disconnections, in the case of a
GracefullyDisconnection, the same socket is used to send data with the disconnection justification, and the same socket is used to receive confirmation of the disconnection justification.Although the asynchronous task handler (tasks_keeper_handle) is being discussed, it was possible to notice that the read handler can receive data from the socket, causing the server/client that is disconnecting with justification to not read the justification, and the code only ends when the disconnection timeout occurs.
Suggestion: add flag in tasks_keeper_handler, to instead of cancelling the handler, cancel each pending task.