Some latency is introduced during normal use of the plugin.
It can be seen after a certain period of use that the events received are not those sent.
In addition, if no action is sent on the client side, nothing is received on the server side, however, when an action is performed, the client-side logs indicate sending the right action while an earlier action is received by the server. This bug makes me think of a form of congestion on the side of the event loop Qt/IDA.
This bug is all the more serious because if for a while, a user performs actions and a second remains on hold, this form of latency will introduce desynchronization. Once the waiting user will re-perform actions, his ticks will be those of the server, unfortunately the server ticks will be lower than those of the active client, a desynchronization will be detected, breaking the plugin.
Some latency is introduced during normal use of the plugin.
It can be seen after a certain period of use that the events received are not those sent. In addition, if no action is sent on the client side, nothing is received on the server side, however, when an action is performed, the client-side logs indicate sending the right action while an earlier action is received by the server. This bug makes me think of a form of congestion on the side of the event loop Qt/IDA.
This bug is all the more serious because if for a while, a user performs actions and a second remains on hold, this form of latency will introduce desynchronization. Once the waiting user will re-perform actions, his ticks will be those of the server, unfortunately the server ticks will be lower than those of the active client, a desynchronization will be detected, breaking the plugin.