TerminatedReadAsync always hits timeout despite returning the terminator. about telnet HOT 4 CLOSED

Sounds like a sort of race condition; the string doesn't terminate with "#" it terminates with "#+the other chars" hence the condition isn't being met. Two routes forward; rework to await the full terminating string (0.8.1's published with your LineTerminator configuration in) or work out why the termination isn't caught in passing?

from telnet.

That's what I don't understand. Doesn't TerminatedReadAsync move one byte at a time?

The Char should be seen as one of those bytes and exit the reading loop ...

from telnet.

Sorry, where did I say the code was perfect and/or bug free? :-p I don't have time to look in to it more tonight; let me know how you get on?

from telnet.

Ok, I think I'm on to something.

The "IsTerminatorLocated" looks at the last char using ".EndsWith".
"TerminatedReadAsync" checks if it's terminated in a loop calling "ReadAsync".

So far, so good. Here is the problem:
"ReadAsync" pulls bytes in a loop based on some rollingTimeout that I don't fully understand.

It looks like the nested read loop inside ReadAsync can return more than one char so that when we get back to the Terminator check, the terminator is no longer on the end.

Two solutions:

1. Change "EndsWith" to "Contains" to detect the terminator across the whole string.
   (This might have performance impacts on long server responses)

2. Change the exit conditions for the ReadAsync loop to ensure we only return one char at a time.
   (I don't understand why we are looping here at all so I'm not sure what the impact would be)

Do you have a preference? Or a 3rd option? I'm leaning towards ".Contains" right now.

from telnet.