I, for the life of me, can’t get either my local or remote side to throw an error (102) when the connection terminates. I could in a previous version. Can any PLEASE confirm this? If this is ANOTHER error in Xojo, I just may lose my shit…
Between issues I’ve had recently with 3rd-party vendors, and the framework errors dealing with daemonization and threads, security certificates in the secure socket, now this (all of which my product relies heavily on), I don’t think I can take it anymore. I purchase a year of the Pro license, I find errors in that release, wait for future releases which resolve those, now these break only to have my license expire in a couple of months. What did I pay for again? I’m getting extremely irritated.
Here is something completely bizarre. When I reset my local system and tried again, the error is now working ON BOTH ENDS as expected. What the heck would cause this? I’ve worked on this over an hour, and am completely irritated (if you couldn’t tell in my initial message), and don’t have the time to reverse this one out… but it’s extremely odd and obviously sporadic. I would have never expected a simple reboot to fix this issue. Anybody have a clue how one remote socket can affect the firing of another’s internal event from firing?
FWIW, the server is on a Windows Server 2012 64-bit machine and the local system is Debian Linux i386 7.6.0 32-bit.
please can you give us more informations about the connection terminated?
The connection terminated because one of the two parties is calling the Close() method or maybe some other event closes the connection?
the two events you are reporting are no valid as connection terminated events reported to the application.
At the application level the close event (error #102) it is reported when the other application executes the Close() method.
That generates a series of frames exchanged between the two systems leading to the connection terminated state.
If you unplug a cable you don’t have theses frames exchanged.
You get some notification when the TCP protocol, handled by the OS, reaches some timeout condition (usually these timeout values are long if you don’t change their default value).
If you forcefully/unexpectedly close one of the application, the OS takes care to send the terminated connection notification to the other system.
Ah, I gotcha. So, this is likely an OS situation (which would explain why resetting the local OS solved the issue). Perhaps it’s something in the new Debian Linux 7.6.0 update that changed the handling of the socket. Hard to fathom that in order to guarantee a successful 102 error, you have to PROPERLY close the connection yourself (which really isn’t an error at all). But, I get it now. I appreciate the explanation, Maurizio.
You really don’t know if a TCP connection is down unless you try to send, and then get an error. You cannot rely on a disconnect notification. It just isn’t part of the TCP world. If you are relying on it, it’s time to redesign your app. Sorry.
So, let me get this straight. You can’t rely on an error 102 being fired at a loss of connectivity (unless it was via an expected close() event, or an OS-level timeout handled it). You can’t depend on the .isConnected either. So, I’m guessing the only way is to send a command to the remote system, and get an ACK back; otherwise, assume the connection is dead?
please try to investigate the " forcefully terminated application" case using a very simple application.
Are you sure you don’t get a close event (error 102) when the other connected application gets terminated?
