Situation as follows using the new scheme asynchronous methods:
After opening a successful connection using socket and the task object, I send a message to my host receiving the right answer and everything is good.
Now, using the same already opened connection I disconnect the Ethernet cable from my station. My procedure which runs continuously gets to the point of sending a message to the host, then
waits for an answer. My expectation was that the Chilkat send procedure SendBytesAsync returns an error, since the connection is not there, but it returns a success.
Then I have decided to monitor the socket.isconnected property, finding that it continues to report the socket is connected for about 20 seconds after calling the SendBytesAsync.
Of course, I need to be able to shut my procedure and not allow for the receiving part to execute, but cannot wait 20 seconds for that.
The SendBytesAsync is simply packaging up the method call and args and returning them in a Task object. The send happens when the task's Run method is called, which schedules the task to immediately run on a background thread.
When the data is actually sent on the socket, it is sent via the "send" socket system call (see http://linux.die.net/man/2/send )
(This is the same for Windows, or any operating system and for any programming language). The "send" system call is simply depositing the bytes to the internal outgoing socket send buffer -- for the operating system to pick up and send. Technically, a TCP connection can stay connected even through temporary physical disconnects (such as when an ethernet cable is disconnected). I would imagine that the operating system is periodically trying to retransmit before finally giving up and closing its side of the connection.
You might try calling socket.PollDataAvailable to see if attempting to read the socket would recognize the disconnected ethernet cable immediately. (Call PollDataAvailable, and then check IsConnected right afterwards.)