User / Display Application Generalization of Framework and Connection
While implementing the ability of the framework to do the reconnect between User Applications when one "failed" (was closed) and then recovered (was reopened), I decided that this was something to also do between the Ada user application framework and the C# Display Application. In thinking about that, I thought that I should first reorganize the Display App somewhat to make it more general; that is, to have the ability to support more than one communications method between the Display App and the User Apps, be able to support more than one Display App (or non-framework based app), and to have the framework support more than one communications protocol (in this case, move the user app / display app interface support from user components to the framework).
In addition, to support the reconnect monitoring, to have heartbeat messages as part of the communications protocol for the User App, Display App interface.
As part of moving the message support between the User Apps and the Display App from cloned user components (one such component for each User App interfacing to a display layer) to a supported communication protocol of the framework it became necessary to be able to differentiate between the framework inter user app supported protocol and the user app to display app protocol.
Since the communications between the user apps and the display app isn't actually ARINC 661, I decided to name it the Display Protocol and the topic based inter User App messaging the Topic Protocol.
The ARINC 661 protocol specification, as updated in "ARINC 661-Supp 3-Adoption Draft1", adds an extended header. This extended header allows some message verification that was previously missing. I have added this extended header to the display event and command messages that I have been using up to now. It contains a leading pair of bytes to identify the message block, the identifiers of the source and intended destination applications, the number of bytes that should be in the message, a health boolean that specifies the source application's determination of whether the destination application is executing correctly, and, among other fields, a message reference number to allow the destination application to check that the messages are received in order without drops. Nothing for a CRC.
The A661 supplement 3 draft document states that messages can be sent with only the extended header. Therefore, I will use that as the heartbeat message to be sent periodically between the two applications and used to monitor the communications bus. This, has yet to be done. It will be implemented along with the reconnect between the user application and the display app.
Display Application Structure
To allow for multiple communication methods and multiple protocols, the C# communication classes of the display application has been rearranged to mimic those of the user application framework. That is, instead of just a MS_Pipe class to use Microsoft pipes to support the communications, there are now Remote and Method classes as well.
The Method class is to select among the supported communication methods for those to be used between the display app and the destination app. That is, like the user app, the communication methods supported by each application in the network is to be specified by a configuration file. The Method class, as more methods are supported, will (as with the user apps) perform the communications with each supported method. For now, Method only selects MS_Pipe as the only supported communications method but it is specified in a configuration file and has to be specified there. As with the user apps, WinSock for instance, could also be supported or supported instead of MS Pipes and then Method would select the class that implements the new method.
The Remote class is the top level class as it is the top level package in the user app framework. That is, an instance of it is invoked when a Windows control (widget) event is received. It contains the common code to add the extended header to the event messages to be transmitted prior to invoking the Method class and to verify the received command messages. Also like the framework package, it has the Watch function that will be used to monitor the message traffic and control reconnects.
Currently, Remote assumes that the Display protocol will be used so the Display extended header is what is added to messages to be transmitted. If the supported protocol changes, this is where the change will be made. Such as if the format of the message data becomes that of the A661 protocol. Or if another type of application is implemented in C# that uses its own protocol.
Configuration File
A display configuration file has been added and the user apps configuration file has been extended. Eventually these two files will be combined into a single file with multiple sections – to start with a User Application section and a Display Application section – but extendable to allow for additional types of applications in the network.
The display configuration file contains the display application identifier and name, the supported communication method(s), and is now where the display Definition File path is specified so it can be moved.
In addition, both configuration files now contain the path to the application's executable so that the first application of the network that is running can cause the others to run. At least those on the local PC and, I suppose, there must be a way to do this over the network as well.
A possible structure of a combined configuration file, might be as follows. In such a structure, the data is organized into groups with possible multiple lines provided for each group. Each line begins with the group identifier and the application identifier to which the group belongs. For easier parsing, the data for a particular groups and applications are in consecutive lines. Or, better yet, this data could be provided in XML.
In the following example of the possible structure, the Group Identifiers are APP, CM, and AP for Application data, for supported Communication Method data, and AP for Addition Protocol data.
In addition to the application id, the Application data provides the application name, the base protocol of the application (currently Topic or Display), the PC on which the application is located, and the path to the executable. In addition, for the Display App, the path of the Definition File to be used is provided.
The supported Communication Method data depends upon the base protocol of the application to provide the data needed by that protocol. Different data is provided for different communication methods. For the MS Pipe communication method, no other data is provided since the Topic protocol between applications provides the algorithm for creating the MS Pipe names. If the WinSock communication method is also supported by the application, the IP Address to be used is provided.
For the Display protocol, the MS Pipe communication method also provides the base portion of the pipe name for communication between the Display Application and the User Application for a particular Layer (1 and 2 for application id 15 in the example). For a Topic Protocol application this data is provided by the Addition Protocol data lines that specify that the additional supported protocol is Display for connection with the application that has 15 as its identifier treating the events of display layer 1. The example illustrates the future possibility of App 1 also using the Display protocol to connect with another application via a different communication method.
The configuration data for a particular application continues as long as its application id is provided.
+–-–+–-–+–
|Gp |App||Id | Id|
+–-–+–-–+–
|APP| 1|App 1|Topic|host PC|executable path|
+––-+–-–+–
| CM| 1|MSPipe|
+––-+–-–+–
| CM| 1|WinSock|IP Address|
+––-+–-–+–
| AP| 1|Display|15| 1|MSPipe|base pipe name|
+––-+–-–+–
| AP| 1|Display|Id|Layer|comm method|
+––-+–-–+–
|APP| 2|App 2|Topic|host PC|executable path|
+––-+–-–+–
| CM| 2|MSPipe|
+––-+–-–+–
| AP| 2|Display|15| 2|MSPipe|base pipe name|
+––-+–-–+–
. . .
+–-–+–-–+–
|APP| 15|App 15|Display|host PC|definition file path|executable path|+––-+–-–+–
| CM| 15| 1|MSPipe|base pipe name|
+––-+–-–+–
| CM| 15| 2|MSPipe|base pipe name|
+––-+–-–+–-+–––––-+–-
Note: Currently, the Display App obtains the supported layers from the Definition File and the communication method and pipe/port name for the layer from the Definition File. This could be another approach. That is, in the Configuration File, provide the nodes of the network via the data of the APP group and includes a Definition File path for each User App as well as the Display App(s). Then provide the communication methods, additional types of applications, etc in the specified Definition File. Perhaps, also a list of each additional application to which a particular application should connect and use that to look up the base protocol of that application, its supported communication methods, etc via its entry in the configuration file.
Display Protocol in Framework
As part of the generalization of the inter app communications the interface with the Display App was moved from separate user components of App1 and App2 to the framework as a second supported protocol. This will allow any user app to interface to the display app (or an additional display app) without the need to clone the previous component for the new application. It will also allow the extension of the monitoring of the connection by the framework and the ability to reconnect as soon as possible.
For the initial shift of this functionality the Com_Display user component was just slightly reworked as the mC-Message-Display framework component with Method and MS_Pipe child packages. This retains a structure that parallels that of the Remote package of the Topic protocol with the Method selector package and the MS_Pipe and WinSock communication method packages. Retained are the Client and Response thread packages under the mC-Message-Display package where the retained Client corresponds to the various Receive threads of MS_Pipe and WinSock.
Response is the thread that awaits responses from user components that register to treat various event messages. It then translates the response to a Display protocol message, including the A661 extended header and transmits it to the display app.
Client awaits the Receive from Method that, in turn, awaits the receive from the display via the MS_Pipe interface acting as the client. (The Display App is the server.) The Method package can be extended to await the message receive of other display methods. When this happens, a further reorganization will put the receive threads in the method packages with one receive thread for each display app to which the network might be extended. That is, with multiple supported communication methods for the Display Protocol and/or multiple display apps configured into the network, the framework Display Protocol structure will need to be reworked again to be more similar to that of the Topic Protocol package structure.
This initial move from individual user components to one framework component structured to retain as much code as possible was only to evaluate the problems that might arise. The one that did – when App2 was also modified to use the framework – was that the two user components had each registered a different clone of the mT-Topic_Widget_Event_Layer and mT-Topic_Widget_Command_Layer topic (e.g., mT-Topic_Widget_Event_Layer1) when the second app's interface to the Display App was first implemented. This was because there could be only one publisher of a One-of-N topic that is used to publish the event to deliver it to the requesting component and only one consumer of the response (the display command) topic. Hence, two versions of the topic were needed.
Therefore, as a workaround, the mC-Message-Display was modified to select the version of these two topics that corresponded to the layer supported by the particular user application that was running. This allows the received event message to be published and distributed to the user component that has registered to treat the event and for that user component to publish the command to be delivered to the new framework component of the application that treats the layer. The Topic Widget Event message is a translation of the data of the received Display protocol message while the response Topic Widget Command will be translated by the mC-Message-Display-Response framework component to a Display Protocol message and transmitted to the Display Application using the connection for the layer.
Future Display Protocol in Framework
Although the above mentioned workaround satisfies the Topic protocol it is not an ideal solution since the addition of other layers would require further clones of the two topics and modification of the particular mC-Message-Display packages to select the correct Ada Topic package and topic Reader and Writer for the display layer.
The Remote framework component makes use of its being inside the framework. When Register Topic messages are received they are evaluated as to whether they apply to the running application. If so, the remotely supplied or consumed topic is registered by the Remote component. Instances of such remotely registered topics are then accepted by the Remote Receive (acting as the consumer) and forwarded (acting as the publisher) – sort of an amplifier – to the topic consumer and any response is transmitted by Remote without using the normal notify mechanism back to the sender. Something similar may be able to done for the widget event and command topics so that the topics are routed correctly without special versions of the topics now that the component is within the framework and has direct access to its private procedures.
Otherwise, there is the example of the Delivery Identifier message exchange delivery style where a delivery id is supplied. This style is specified for the Widget Event topic where multiple user components can register to consume the topic but also supply the delivery ids that will be treated. For the Widget Event topic the widget id is supplied as the delivery id and the framework only delivers the topic to the component that has registered to treat that particular delivery id. This can be considered One-of-N in that there can be N consumers of the topic but only one can receive a particular instance of the topic – the one that registered to treat the delivery id.
In addition, there is the Request/Response message exchange delivery style that is N-to-One; that is, N possible producers but only one consumer. In addition, the Response published by the consumer is only delivered by the framework to the component the published the request and only if it registered to consume the response.
Therefore, either a new message exchange style that combines these features could be created or the Delivery Identifier style could be extended to allow a response with that response delivered to the publisher of the request.
Either way, the Widget Event and Widget Command topics would be combined into a paired topic with a request (the display event) and a response (the display command). The request would be delivered to the consumer that registered for the delivery (event) id and the response would be delivered to the component that published the request. If an extension of the current Delivery Identifier delivery style is selected, then other topics of this style wouldn't be paired and there would continue to be no response to deliver. This would be a One-of-N-to-One delivery style.
Another possible direction to follow is that developed for the Foreign language components that could register, through another private framework interface, their own version of an Ada topic. It can be checked whether the topics would get delivered correctly if the Display component used the Foreign interface Register to register C versions of the two topics so that the Ada generic Topic Writer and Reader could be bypassed.
Display Communications Monitoring
Now that both the Display Application communications is in the Remote and associated classes and the User Application communications to the Display Application has been moved to within the framework, the Display Protocol communications can be monitored similarly to the Topic Protocol inter-application communications. As well as attempts to reconnect after a loss of communications.
Currently the Display app only sends messages when a widget event occurs. This won't be sufficient to recognize a continuing connection via the Watch procedure of the Remote class / package. However, now that there can be the Extended Header-only message, it can be sent as a heartbeat message periodically by both the user app and the display app and the Watch procedure can monitor for an ever changing received message count. If the count stays the same, it can declare a disconnect.
Likewise, a disconnect could also be declared for the MS Pipe class/package when the pipe interface recognizes the disconnect. This can be signaled to the Watch procedure by the setting of a boolean in the class/package's Comm structure for the Watch procedure to monitor.
After a disconnect, the framework (and Display App) can attempt to get the pipe connected again.
Other Associated Additions that could to be made
During my ARINC 661 work at an aerospace supplier, the user application was tracking changes to the display. This would have allowed a certain amount of recovery if a temporary loss of communications (such as the display computer resetting) occurred. The displays could have been restored to the last assumed display status (that is, to the state that they would have had if the last commands sent had been received and act on). Or, to the state of the last saved checkpoint.
Some future addition to my exploratory project could retain some information about what was displayed to be able to recover somewhat from a disconnect. Without this, the display can only redisplay the initial display after it begins execution once again. (Of course, if the problem really is in the connection, the display will continue unchanged, except that it could display a Loss of Connection popup.)
Windows does some of this but not much. That is, the desktop displays particular icons and toolbars upon each start and the like, but does not relaunch user applications that were running. It now seems to relaunch Windows Explorer but only to display the startup page. Particular applications such as Ultra Edit, if closed, will open the same files that were opened when the application was closed. So certain applications have persistence to varying degrees.
