Hello,
I am working through a POP3 client exercise and I need a TcpClient that does not block.
I've gotten 80% of the protocol pretty well nailed down but for retrieving messages, which I am finding I need to rework the reply-receive strategy. Up to now it's been a generic approach and it's worked well.
Using the TcpClient GetStream, wrapped in an SslStream as appropriate type thing to start with. Using a Command-Reply-Transaction pattern, commands write using either direct Stream calls, or I have found the StreamWriter is effective. Similarly for Reply,
using Stream BeginRead methodology, works up to a point, but tends to fall over on TcpClient-streams being blocking. I was using StreamReader ReadToEndAsync().Result with limited success, I suspect for similar blocking issues. This would be the best possible
solution because it's a clean, simple call to read what I need from the stream.
I've read in places where possibly the TcpClient Client ReceiveTimeout can be tweaked. That's one potential solution.
If I can't find a solution soon, I may just "outsource" for a "working" library and run with it. It'd be worth the couple of hundred bucks for single developer license for the problem that this is I think rather than contending with it again.
Any solutions to this "known issue"? It's not a bug per se, only in this instance behavior must be non-blocking for things to work well.
Thank you...
Regards,
Michael