Background
As part of the monitoring of the Exploratory Project communications in order to detect a dropped connection I decided it was time to move the treatment of the communications with the Display application from user components to the framework. This was overdue since, with the addition of a second user application to interface to the display application, the user component had to be cloned and would have to be cloned again for every user application that needs to interface with the Display application. And, as part of the framework, additional protocols can be supported (as specified in the configuration files) and additional communication interfaces such as the WinSock interface supported for communications between user applications.
When I did this I got a surprise due to a fading of my memory of what I had had to do when I had added the second user application to interface with the display. With the making of the user component into a framework component I had to remove my cloned topics that the user components supported so as to have only one Display Widget Event topic to translate a display protocol event message into a framework topic. This because can't continue to add cloned topics since now a part of what should be a stable framework. Therefore, it was necessary to come up with a way that the common framework of each user application could determine when the Display Widget Event topic needed to be forwarded to a remote user app when the local app also had a consumer for the topic.
In addition, the move of the display protocol to the framework highlighted another problem with the previous framework topics. That is, I originally created the Delivery Identifier message exchange topic category knowing that I wanted to be able to forward a display widget event to the particular component that registered to treat the particular event identifier. That is, one topic produced by possibly multiple components and only delivered to the one of multiple potential consumers that registered to treat the particular delivery identifier.
When it came time to actually implement this the treating component had to send a display update command topic to be translated to the display protocol message to be transmitted to the display application. At the time, this was handled by using a Request / Response message exchange topic category (with no response requested) with the particular user display component registering to consume the request. Again, with the display component becoming part of the framework, it would only be able to register for a common single such topic since not able to treat extra cloned topics as additional user applications interface to the display.
This again was something I should have recognized at the time that I added the interface of the user application with the display and had to have the user component respond to the received widget event.
Requested Delivery Message Exchange
Therefore, while implementing a common Display Widget Event topic to be published by the framework display component upon the receipt of the display protocol message, I created a new message exchange topic category of Requested Delivery. This category combines Delivery Identifier and Request / Response where there can be multiple producers of the topic (in this particular case the multiple instantiations of the framework display component – one per user application) and multiple consumers with only one particular consumer registering to treat a particular delivery identifier. This is the same as Delivery Identifier. In addition, there is a paired response topic as with Request / Response where the response is returned to the particular request publisher.
Instead of One-of-N delivery (one consumer of N possible) as with Delivery Identifier and N-to-One delivery (N producers to one possible consumer with the response returned to the particular request producer) as with Request / Response, there is One-of-N-to-One delivery where the message is delivered to one consumer of N possible consumers and the response is delivered to the particular request producer.
Therefore, the framework of one user application can receive a Widget Event message from the Display application, translate it to the common Display Widget Event topic and publish it. The framework then determines which component of what application registered to treat the widget id of the message and forwards it to that component. The component treats the event and creates the new instance of the response topic and publishes it. The framework then returns the topic instance to the component that published the request. Since this will be the framework display component of a particular user application, it converts it to a display protocol message and transmits it to the Display application.
The implementation of this new Requested Delivery message exchange resulted in a number of challenges to be solved. That is, when there were cloned topics, the consumer of a particular delivery id by a particular component could be determined at topic registration time and the publisher of the particular cloned topic was known. With the change to Requested Delivery, the consumer can be known but not the particular producer since the delivery id to be produced isn't known until it is received from the Display app and hence published by the framework display component. For instance, the framework Display component of each user application will register as the producer of the Display Widget Event request message.
The registration of the producer of a particular delivery identifier has to be delayed until the topic is actually published with the delivery id although it continues to register as a producer of the topic in general at registration time. To do this, another group of items was added to the Register Request messages exchanged by the user apps along with tables to know what components have registered to consume particular delivery ids. This group of items contains all the components that have registered to consume the Requested Delivery topic along with the delivery ids that each component has registered to consume. Then, when a topic is published, the table created due to these lists can be used to determine what application registered to consume the particular identifier.
If the consuming component is in a remote application, the framework sends the topic to that application. The framework of that application then looks it up in the table used prior to this change to determine the component to which to forward the topic. If not in that table, it registers the topic and component as specified in the newly added table so it can be processed in the usual way for the response and any additional instances can be found as received. That is, the producer of the delivery id is now known so the framework can determine the component to which to return the response.
With these changes, messages such as those received from the display can be forwarded to a user component that has raised its hand (registered) to treat a particular instance of the topic (as identified by a numeric value) and the resulting response message can be returned. And there can be multiple components that produce the topic although, hopefully, not with the same numeric identifier.
This is the case with the ARINC-661 protocol where different layers can be interfaced with different user applications – one layer to one user application. Or, with the ARINC supplement 3 draft document (http://wn.com/ARINC_661), one application treating multiple layers as long as the widget identifiers of the layers are unique. There must also be other examples where this new message exchange category can be applied.
Framework Component Structure
The structure of the components of the framework that are directly involved with communications is illustrated in the Framework Components diagram.
Note, framework components are similar to user components except for being an integral part of the component. That is, they register as a component with the framework, register the topics that they will produce and consume, have a process/thread in which to execute, etc. They are dissimilar in that they can reference various framework types and variables.
As shown in the diagram, there is a Remote package installs itself as a component while requesting that its non-install code run under a Remote process thread. In this package are a group of tables that are used to determine topics to be transmitted and validate received messages as to whether they are expected. (If not, they are rejected.)
Validated received messages (each received in one of the Receive process threads of MS_Pipe or WinSock packages – one thread per possible remote user application) are added to the Receive Queue and with the framework then signaled to run the Remote thread. This also updates the Connections package watch tables used to monitor whether reconnect attempts are needed.
Messages to be transmitted are added to the Transmit Queue and the framework is signaled to run the Remote thread. (Each time the thread is run it checks both queues.) Messages in the Transmit Queue are passed along to the Method package to transmit the message by each supported and connected communication method as implemented in transmit procedures of the MS_Pipe and WinSock packages.
The framework also wakes up the Remote thread periodically to send heartbeat messages in case components haven't queued Topic messages to be transmitted.
The Display interface is implemented within a Display package. It installs Client and Response components where its install registers with the framework to provide corresponding Client and Response process threads. Received display messages are translated to Requested Delivery request topic messages in the Parse package and then published for the framework to deliver to the consumer of the widget identifier. The Client component acts as if it is the Response component when doing the publish so that the response will be delivered to the Response component. The Response component then transmits the response, via the display protocol, to the Display app.
If the framework determines that the consumer for the published Requested Delivery request is in a remote application, it uses the Remote component by inserting the message in the Transmit Queue.
Maintaining the Connections status for the communications with the Display has yet to be implemented. The initial move of the display protocol to the framework retained the previous user component structure for Client and Response while adding the Method package to allow for different methods to be supported. While doing the display communications monitoring the use of Remote Connections and common method packages will be examined.
Protocols
With the move of the Display protocol to the framework it became necessary to be able to distinguish between the protocol that the framework previously implemented and the new one that it can also handle. As well as the ability to designate other protocols in the future. Therefore, as mentioned in the most recent previous post, the prior framework protocol will now be referred to as the Topic Protocol while the current protocol between the user apps and the display app will be referred to as the Display Protocol. This is because it isn't really ARINC-661 and naming it the Display Protocol will allow a future implementation of ARINC-661 to be referred to as the ARINC-661 Protocol.
So now the framework supports Framework Topic protocol messages and Display protocol messages in a more or less common structure.
