Framework Reconnect Following Loss of Connection

Framework Reconnect Following Loss of Connection

Something that I had been putting off was the ability of the Framework to reconnect to a remote application after the loss of the connection between local (i.e., currently running) application and any of the remote applications.

This involves any of the various protocols; currently the Framework MS Pipe driver protocol, the Framework WinSock driver protocol, and the MS Pipe protocol between an user application and the Display Application.  This latter protocol currently is implemented via component driver rather than being part of the Framework.

Of these connection protocols, I have now modified the Framework to reconnect with a remote user application if they communicate via MS Pipes.

A Watch method has now been implemented as part of a previously existing Remote thread that runs in a forever loop at particular rate.  This method determines whether messages are being received from the various remote applications of the configuration.  (Note: Heartbeat messages should be received even if no other activity between the applications is necessary.) 

The Watch method would indicate a connection whether the activity is via either of the two inter-user application protocols.  In order to make testing easier (that is, the need recognize a new connection), the supported connection protocols for each user application of the configuration was set to only MS Pipe so that WinSock connections were not attempted.

When the Watch method detects a disconnect between the local application and a particular remote application, it performs the Windows interface functions to close the driver and then signals the Remote Main thread that the topic tables indicating which topics were being satisfied by the remote application need to be purged.  The Main thread then calls a new procedure to do so.  The remotely registered topics are retained however since they are links in chains in Framework Memory that doesn't use garbage collection.  Instead, upon reconnect with the remote application, reconnect is indicated when the remote topic is again registered so as to ignore what would be a duplicate registration.

Currently both possible drivers are closed – if previously opened.  This will have to be changed so that the watch is by connection method with a particular method driver closed if it stops receiving messages while not signaling the Remote Main thread unless there was no other working protocol.  This being so that if one protocol fails but the other continues, the failed protocol will be reverted to its initial condition in case the connection can be reestablished.

The building and sending of the Remote Register Request message was changed so that no longer happens as soon as startup is finished and continues to be attempted to any possible remote application satisfied. 

Since with disconnect from an application, some of the remote topics can continue to be satisfied by another remote application there is no need to attempt to determine what remote applications can satisfy those topics.  Therefore, a different Remote Register Request message is needed.  Although not addressed before, the same is true if one remote application is launched and establishes a connection early on and another not until much later.  Then some of the needed topics of the local application will already have been satisfied and there is no need for them to be included in the Remote Register Request message sent to the late connection.

Therefore, the new Watch method detects when a connection has been established and sends an event to the Remote Main thread.  The Main thread then does a modified build of the Remote Register Request that is only meant to be sent to the newly connected remote application.  The first time the message will contain all the topics that can't be satisfied by the components of the local application – the same as occurred before.  However, when another remote application is established, the Remote Register Request message to be sent to it won't contain the topics that were satisfied by previously connected applications.  (Note, if the next connection occurs before the previously connected applications can complete the remote registration sequence, then the message will still contain topics that will be satisfied by an earlier connection.)

The Remote Register Request message is then only transmitted by the Remote Transmit thread to the particular remote application rather than broadcast to all possible applications of the configuration.  Since it is now known that the remote application does have a connection, the Remote Register Request message is deleted after it has been transmitted and not attempted each time the Remote Transmit thread is run.

This new connection and remote topic registration was tested by quitting/stopping a particular application to break the connection and then restarting/relaunching it.  The other running applications detected the disconnect by the lack of received messages and did the reconnect sequence explained above.  The relaunched application does its normal startup and sends its own Remote Register Request message when the connections with the other user applications is detected.

In order to see the console log of the relaunched application, I changed the open of the console log to append to the existing log if less than 10 seconds had elapsed since the log was last modified.