TerminatedReadAsync gets stuck in WPF but works in WinForms

[chodurkhyun]

First of all, thank you for creating and maintaining this excellent Telnet library. I've been using it successfully in a .NET Framework 4.7.2 WinForms application, and it has worked great. However, I'm encountering an issue when migrating to .NET 8.0 WPF environment (on Windows 11). The connection only works properly when milliSecondSpin == 0. When using non-zero milliSecondSpin values, the TerminatedReadAsync method gets stuck.

Interestingly, sometimes after waiting several minutes, it suddenly proceeds, but this behavior is inconsistent.

The server I'm connecting to works perfectly fine with the Windows Telnet client, so the server implementation appears to be standard-compliant.

Belows are my questions:

1. Are there known issues or special considerations when using this library in WPF applications?
2. Is there a recommended configuration or workaround for WPF applications?
3. Why does setting milliSecondSpin = 0 resolve the issue?

Any guidance would be greatly appreciated.

[9swampy]

First of all, thank you for creating and maintaining this excellent Telnet library. I've been using it successfully in a .NET Framework 4.7.2 WinForms application, and it has worked great. However, I'm encountering an issue when migrating to .NET 8.0 WPF environment (on Windows 11). The connection only works properly when milliSecondSpin == 0. When using non-zero milliSecondSpin values, the TerminatedReadAsync method gets stuck.

Interestingly, sometimes after waiting several minutes, it suddenly proceeds, but this behavior is inconsistent.

The server I'm connecting to works perfectly fine with the Windows Telnet client, so the server implementation appears to be standard-compliant.

Belows are my questions:

1. Are there known issues or special considerations when using this library in WPF applications?
2. Is there a recommended configuration or workaround for WPF applications?
3. Why does setting milliSecondSpin = 0 resolve the issue?

Any guidance would be greatly appreciated.

Instant thought: are you aware of and have you applied Configure await(false)?

[chodurkhyun]

First of all, thank you for creating and maintaining this excellent Telnet library. I've been using it successfully in a .NET Framework 4.7.2 WinForms application, and it has worked great. However, I'm encountering an issue when migrating to .NET 8.0 WPF environment (on Windows 11). The connection only works properly when milliSecondSpin == 0. When using non-zero milliSecondSpin values, the TerminatedReadAsync method gets stuck.
Interestingly, sometimes after waiting several minutes, it suddenly proceeds, but this behavior is inconsistent.
The server I'm connecting to works perfectly fine with the Windows Telnet client, so the server implementation appears to be standard-compliant.
Belows are my questions:

1. Are there known issues or special considerations when using this library in WPF applications?
2. Is there a recommended configuration or workaround for WPF applications?
3. Why does setting milliSecondSpin = 0 resolve the issue?

Any guidance would be greatly appreciated.

Instant thought: are you aware of and have you applied Configure await(false)?

Thank you for the response.
Yes, I've already tried that, but unfortunately it's still not working.
After adding some console logs, I found that when TerminatedReadAsync() calls ByteStreamHandler.ReadAsync(), the program gets stuck in the do-while loop of ByteStreamHandler.ReadAsync() because IsResponsePending remains true.

(+ I found that my .NET 8.0 Console App has the same issue and my .Net Framework 4.7.2 Console App (which has the same source code) works properly)

This seems to be preventing the async read operation from completing. Do you have any insights?

[chodurkhyun]

Further Investigation:
I discovered that in the failing cases, the do-while loop is stuck in an infinite negotiation loop:

Server sends: IAC WILL SGA
Client responds: IAC DO SGA
Server sends: IAC WILL SGA (again)
Client responds: IAC DO SGA (again)
... (repeats indefinitely)

As a test, I modified the code to respond only to the first IAC WILL SGA and ignore subsequent identical requests. This seems to resolve the issue.

I don't know why does this negotiation loop behavior differ based on the milliSecondSpin value and why doesn't this issue occur in .NET Framework 4.7.2. (and I would like to know it)

Is there an existing configuration or option in the library to control this negotiation behavior?

[chodurkhyun]

Hello @9swampy !
I've been investigating the problem further. I believe I've identified the root cause and have a potential solution.

What I found:

• I confirmed that the negotiation loop can occur when communicating with my target server. This appears to be a more fundamental issue rather than just a difference between .NET and .NET Framework.
• I verified this through console logs and Wireshark packet analysis.
• Setting the milliSecondSpin parameter to 0 makes it work properly on .NET 8.0, while .NET Framework seemed fine with the default value of 1. However, any value higher than that causes the same loop issue on both platforms.
• Even with smaller parameter values, it's not that the negotiation loop doesn't occur - it still happens but gets resolved by other termination conditions.
• Since this stems from SGA options, I also tried disabling the ProactiveNegotiation option, but it had no effect.
• Ultimately, I decided to implement the FSM from RFC1143 and created a prototype. Testing shows this resolves the issue in my case.

My question:
Would it be okay if I clean up my experimental code changes and submit a PR with this fix? I'd be happy to share my findings and the proposed solution for review.

Let me know if you'd like me to proceed with the PR or if you need any additional details about my investigation.
Thanks!