Alljoyn thin client library introduction (translated by official documents)

The translation is completed only now due to other delays. Next --

4. thin client core Library Architecture

Because the alljoyn thin client core library (ajtcl) must run on devices with limited power consumption, limited computing power, and limited resources, as a result, it cannot use the same architecture as alljoyn's standard core library (ajscl) as it runs on general-purpose computer systems.
The hierarchy of an ajsl or service process is shown in 3. The article introduction to the alljoyn framework describes more detailed details of these hierarchies. Note that each alljoyn client or server program uses this hierarchy to build the alljoyn application.

At least one routing program must be run on each host running ajcl. This routing program can run in the form of a separate routing process, or run in an application. The hierarchical structure 4 of the ajcl routing program is shown in.

Note that the routing program can provide additional support for message transmission between route nodes and support multi-network transmission mechanisms such as Wi-Fi direct. This function can effectively reduce computing power consumption and memory overhead.
We obviously cannot run such a number of programs in an embedded system, so ajtcl minimizes the amount of code required to run on a given device. Ajtcl only uses the most basic C operating environment and uses the computing power of other devices to implement routing rules. As shown in figure 5, compared with ajcl, ajtcl removes most of the ajsl system overhead. Ajtl only provides a small number of required APIs (application interfaces) for bus pendants, and provides alljoyn message interfaces directly to programmers, rather than indirect interface functions.

The message layer does not provide an abstract transmission mechanism, but directly uses the user data block transmission protocol (UDP) and TCP protocol. The port layer in the layered structure is very simple, and several simple local system functions are required. To minimize the size of the Code, it is fully written in C language. With these optimization mechanisms, an ajtcl system can run with only 25 KB of memory, however, an application bound with the routing function and the C ++ client and server program may require 10 times of memory overhead, the alljoyn program of a Java language requires about 40 times of overhead.

5. Integrated Operation

 

In order to make the discussion in this chapter more specific, we have made two examples of distributed systems. The first example is a minimal alljoyn system consisting of an alljoyn application running on a smartphone and a simple ajtcl device. This example describes the routing relationship described above. The second example is a little more complex, including a routing program running on a wireless router.
Note that a router running the openwrt system runs the pre-installed alljoyn routing program. This routing program accepts non-trusted connection requests from thin client libraries connected to the Wi-Fi network.
A small number of ajtcl devices are connected to routers and act as sensor nodes in a alljoyn-based wireless sensor network, while a general-purpose computer completes data fusion.
In wireless sensor networks, data fusion integrates the results collected by different nodes or the results obtained by other sensor nodes, in order to make decisions.

5.1 A minimum thin client system

 

A minimal ajtcl-enabled system includes a host running ajcl and a thin client device. Ajcl provides the alljoyn routing function for the thin client to be connected to, and also provides a platform for applications that use thin clients. As mentioned above, thin client devices usually act as sensor nodes and send messages to applications running on the host. The application processes the information in some way and sends commands to the sensor node so that it can cope with the current environment.
Consider a simple, but possibly under-consideration situation where a wall-mounted thermostat controls an electric stove and runs a control application on an Android device. The Android device runs ajcl, while the wall-mounted thermostat runs ajtcl. The system can be represented in figure 6.

In this example, a wall-mounted thermostat can only be controlled by the thermostat control program corresponding to Android devices.
Although the requirement in this example shows that the thermostat can only be controlled by Android devices, the requirement can also be that the thermostat connects to a route node and then the route node connects to the application. This means that the Android Application should be bound with the alljoyn routing program, and the routing program and application bound together should be provided to the thin client as a routing node. This configuration allows you to establish a trusted relationship between ajtcl and the routing node/application.
The application then requests the route program bound to it to send a "quiet" broadcast (for example, Com. Company. busnode <guid>) to ajtcl in a well-known naming method ). The routing program then prepares to respond to the quiet (unicast) Replies named after the previous broadcast. When a thin client appears, it should enable the discovery process on the associated network prefix (COM. Company. busnode), as shown in 7.

When a routing node receives a clear request for its previously "quietly" broadcast name, it will respond to a message indicating that the name is broadcast by this routing node. Then ajtcl tries to connect to the response route node. Process 8.

In this way, a logical alljoyn bus has been established, and applications and thin client services are connected by routing programs running on Android devices. The system is represented by a bubble Chart Used in "Introduction to the alljoyn framework". This configuration looks like alljoyn routing node connects the server program and client program, as shown in figure 9.

At this time, ajtcl has been connected to the routing program bound to the application, but the application and thin client do not know each other's existence. Generally, ajtcl requests a well-known bus name and instantiates a service under the awareness of alljoyn. As described in introduction to the alljoyn framework, thin clients use the API interfaces of the core library of thin clients to create a dialog port and broadcast a well-known name. This name is generally not the same as the name of the route node broadcast; it is related to the relationship between the thin client and the client/server between the application, but not the relationship between the routing node and the thin client. Applications running on Android devices will run the Discovery Service for this name, as shown in figure 10.

When a service running on ajtcl is discovered by a client running on Android devices, the client will join the conversation created by the Service.

From this perspective, applications running on Android devices can access ajtcl services and any alljoyn services. It may report the signal sent by the service-in this example, it may include the periodic signal of the current temperature. This application may build a user interface that allows users to enter the desired temperature and send the temperature to ajtcl using the alljoyn remote method described in introduction to the alljoyn framework. Once a call method is received, the service program running on ajtcl forwards the request to the electric furnace to set the ideal temperature.
The APIs used on the thin client are very different from those used on the ajcl or service program. In both cases, the transfer protocol is identical, however, for one party, the traits of the other component are invisible. In this regard, alljoyn is unique, and the bubbles in the previous block diagram, including thin clients, have no difference in purpose or behavior.

5.2 A thin client-based Wireless Sensor Network
This example describes a very basic home management system. The Wireless Access Point of the system is a router running openwrt, on which a alljoyn routing program that allows non-trusted connections from thin clients is preinstalled. In this way, the ajtcl client can connect to the routing node to access the system. The thin client device in the network can be a temperature sensor, motion detection sensor, electric switch, water heater, electric furnace or air conditioner.
As mentioned previously, the Data Fusion function in this example is implemented and integrated by an application running on a general computer. This does not mean that there must be a general-purpose computer in the network-data fusion can be implemented in other ways; however, in this example, a general-purpose computer can help us understand how ajcl interacts with thin client devices. Integrated Display can be displayed on a wall-mounted display device or simply on a PC at home. For example, the display program can provide user interfaces for temperature controllers and thermometers in different rooms; it can also be a virtual electric switch or a motion detector. The data fusion algorithm program determines when to turn on the light, how to control the switch of the electric furnace or air conditioner, or how to control the temperature of the water heater most effectively.
The first component to be considered is the openwrt router shown in 12. The vro controls an independent alljoyn routing domain (in the figure, it is indicated by a thick black horizontal line, representing a bus segment of an alljoyn distributed software BUS ).

There is an alljoyn service program in the bus segment where the router is located. This program uses the alljoyn architecture to provide a way to configure the router and the routing program preinstalled on the router. In addition, some empty slots in the figure indicate non-trusted connections with ajtcl. Because this is a general alljoyn router, the corresponding software BUS can be extended to other bus segments to form a Distributed Bus shown in 1.
As described in the previous section, the ajtcl device runs the discovery process to search for the routing nodes they can connect. Although this describes a non-trusted relationship, the alljoyn routing program running on the openwrt router can be configured to "quietly" broadcast a common name, such as Org. alljoyn. busnode indicates that the routing node is a node on the alljoyn Distributed Bus and intends to take over the thin client.
The ajtl device representing the sensor node connects to the wireless network through the login process. In this process, they are named by a so-called friendly name (that is, a meaningful name. For example, one electric light controller (On-Off-Dimming Controller) may be named "Kitchen", and the other may be named "bedroom ". The corresponding thin client nodes start to explore the routing nodes they connect to (probably org. alljoyn. busnode) and try to connect. Although many "slots" in it assume that they are not trusted, thin client devices can still join the network as shown in Figure 13.

Once the thin client program is connected to the bus segment of the openwrt router, it starts to broadcast its corresponding services. As previously assumed, this is a home control system that connects to the wireless network provided by the router. This device will try to discover services and find the services provided by the thin client library in the system, as shown in figure 14.

Once the home control system discovers a thin client broadcast service, it will try to start a conversation with the thin client. The result is that the bus segment of the router and the home control system are integrated into a virtual Distributed Bus.

When the integrated bus is fully formed, the device connected to the bus becomes a standard alljoyn client or server. Other components on the fabric device do not know that these alljoyn thin client sensors/actuators are actually embedded devices and connect to the alljoyn routing node through the TCP protocol, I do not know that the home control program is written in Java and runs on a general-purpose computer running Android. These clients and servers only execute remote call methods and send and receive signals.
Readers can now understand the algorithms running on Data Fusion nodes. Examples. An important alljoyn signal transmitted on the Distributed Bus may be something that corresponds to carbon-monoxide-detected (detected carbon monoxide. This signal will be received by the home Control System (data integration center. After receiving this signal, the home control system may send a remote method to an execution node to make it TURN-FAN_ON (open the fan), it may also send a remote method to another execution node, the sound-alarm may also send text messages to the house owner, telling him that there is excessive carbon monoxide in the house.
In more common cases, the home control system may also send a remote method to the electric furnace so that it is no one in the room (based on the detection results and calendar of the motion detection device) reduce the room temperature. The Housing Control Unit may send a message to the water heater to reduce the water temperature during working hours and midnight, and send a call method to it when the midnight timer needs to work to increase the water temperature, in this way, you can work at the lowest cost.
All the signals and call Methods returned by these home control systems are completely independent of the type of signal sending/receiving devices.

6. Conclusion
Alljoyn is a comprehensive system designed to develop distributed applications on systems with different components. Ajtcl allows embedded devices to be added to the alljoyn distributed software bus and can exist in the system in a way that ignores the details, which is a headache for developers. This achievement allows application developers to focus on the content of the application without having to consider too many underlying and embedded system networks.
The alljoyn system can work together as a whole. Unlike the point-to-point network, the inherent mismatch between different nodes may cause many problems. We believe that compared with applications developed on other platforms, the alljoyn system can build more powerful distributed applications including embedded devices in a simpler way.

Learn more
For more information about how to use alljoyn in development, visit and download the relevant documentation on the allseen Alliance website: (www.allseenalliance.org)
Description specification-describes alljoyn technology and related concepts.
Development description-describes how to build an environment and provides solutions for special problems, including comments of code snippets.
API reference-provides details about how to use alljoyn source code to write applications in all supported programming languages.
Download the software development kit (SDK), which provides resources to help you compile, modify, test, and execute a project.

 

After reading this, what do you think ??

 

Alljoyn thin client library introduction (translated by official documents)