Currently, if an intercepted client disconnects while their session is hijacked, PyRDP will ignore the request for disconnect until the RDP client times out, after which point both connections (client - pyrdp and pyrdp - server) are disconnected. Dropping the hijacked session in the process.
It would be nice and not too complicated to disconnect the client smoothly while keeping the hijacked session active.
This would also require minor UI improvements to mark the state of the client (something simple like: idle, active, disconnected)
In fact, this might be a whole other feature that ties in with #148 and gives a smoother experience to session hijacking.
Currently, if an intercepted client disconnects while their session is hijacked, PyRDP will ignore the request for disconnect until the RDP client times out, after which point both connections (client - pyrdp and pyrdp - server) are disconnected. Dropping the hijacked session in the process.
It would be nice and not too complicated to disconnect the client smoothly while keeping the hijacked session active.
This would also require minor UI improvements to mark the state of the client (something simple like: idle, active, disconnected) In fact, this might be a whole other feature that ties in with #148 and gives a smoother experience to session hijacking.