Role of ConnectedMonitor in SimpleTcpClient

[MeirBen]

Hi,

First of all, thank you for this library! It has been incredibly helpful, and I really appreciate the effort.

I have a question regarding the necessity of the SimpleTcpClient connection monitor (ConnectedMonitor) in the context of the ReadAsync loop within the DataReceiverAsync method. My understanding is that the DataReadAsync loop inherently handles disconnections in two primary ways while waiting for data:

Graceful disconnects: When the remote endpoint closes the connection properly, the ReadAsync call returns a 0-byte read.

Abnormal disconnects: In cases of unexpected failures (e.g., network issues or crashes), ReadAsync throws exceptions such as IOException or SocketException.

Because the ReadAsync loop detects both scenarios directly during its waiting period—by either returning 0 or throwing an exception—the disconnection is logged and resources are cleaned up immediately.

Given this setup, it seems that the ConnectedMonitor task might be redundant. The continuous ReadAsync loop appears to be sufficient for disconnection detection on its own. Could you clarify if there are specific scenarios where the connection monitor adds value beyond what the DataReadAsync loop already handles? Is there a benefit to having both in place, or might the monitor be unnecessary for most use cases?

Thanks!

[jchristn]

Hi @MeirBen thanks for the kind words. I've found differing behavior across operating systems and frameworks, and in many cases, it may be redundant. Unfortunately due to the minor differences amongst the combination of frameworks and operating systems, and forgive me for not remembering which one specifically required me to brute force this, I implemented the connection monitor to overcome a lack of disconnect detection. If you test it in your environment and it is redundant, by all means, remove it. Cheers, Joel