.Net 6 compatibility

[Wildimp]

Hey @MarcusWichelmann,
first of all I'd like to thank you for providing a .net vnc implementation :)

I was trying to implement your vnc client into an existing .net 6 Wpf project. It works great with a stable internet connection, but as soon as there is packet loss it gets wonky. The vnc client gets unresponsive for an undefined amount of time between 10 and up to 45 seconds (which was the highest I saw). After that It throws the following exceptions one after another and crashes in the end:

System.IO.IOException: 'Unable to read data from the transport connection' at Line 142 in StreamExtensions
System.OperationCanceledException: 'The operation was canceled.' at Line 125 in RfbMessageSender
System.PlatformNotSupportedException: 'Thread abort is not supported on this platform.' at Line 131 in BackGroundThread
System.ObjectDisposedException: 'The collection has been disposed. ObjectDisposed_ObjectName_Name' at Line 193 in RfbMessageSender

In order to create artificial package loss for testing I used a little networking tool called clumsy if that matters. https://jagt.github.io/clumsy/

As the third Exception states Thread.Abort() is not supported on this platform, I guess that there is a compatibility issue with .net 6 here?
I tried your Avalonia example and it works just fine and it reconnects after a maximum of 30 seconds. Your example targets .net core 3.1 if I got that right.

Is there a way to get this running in .net 6? Or is it maybe not even an issue of .net 6 and I am just missing something here?

On top of the described issue I also can't use the RfbConnection.CloseAsync() as it never returns after the await. This also might be related to .net 6 but i am not sure. But this issue is only minor and I can work arround it but maybe you have an idea why this happens.

Kind Regards
Luis Payer

[MarcusWichelmann]

Hi,

cool, that it is useful for you.

The RFB/VNC protocol is not resilient against lost data, which is why the connection crashes when that happens. But this is normally not an issue, because the underlying TCP protocol should validate checksums, handle packet loss and trigger retransmissions, if necessary.

If you see connection hangs because of this, I'd recommend to look at a deeper level (Wireshark), why the TCP connection gets terminated somehow.

I don't think this is .Net 6 related. The only difference with the Avalonia example might be that it automatically reconnects?