One size does not fit all. Depending on the project, data transport requirements may vary drastically. Protocol reliability, security, data consumption, transport delay, computational complexity, energy budget, and many other criteria have to be factored in when choosing a means for communicating with the endpoints.
This is why Kaa is designed to support virtually any data transport protocols. Moreover, the platform enables developers to use different transport protocols for its different functions performed over the same endpoint. For example, notifications can be delivered with SMS messages, whereas configuration and profile data - with TCP. This ability is achieved by abstraction of the transport layer that advertises its capabilities to the Operations server when establishing a transport channel. Each channel supports a specific transfer protocol and is responsible for data encoding, compression, and delivery.
Kaa provides readily available implementation of transport channels for all Kaa services that it could use by default. Programmers can create custom implementations of transport channels for all or some of the Kaa services that would override the default data channels. Both the endpoint and the Operations server differentiate between the transport channel instances and select an appropriate channel for sending data during a specific session based on predefined rules.
Each of the Kaa services is responsible for specific data exchange functionality, as described below:
There are two options for assigning a transport channel to a service. One is to assign a separate transport channel to each service. The other option is to combine all or some of the services and assign them a common transport channel. However, at any moment one channel can maintain only one open session.
Each transport channel is capable of transferring Kaa data in one of the following modes:
If multiple channels are created for work in the upstream mode for any service, Kaa always uses the most recent channel. For example, if one channel works upstream for three services (configuration, notification, and events) and another channel that was created and registered later works upstream for one of those services (for example, notification), then the notification service will communicate upstream through the second channel only.
However, Kaa can use multiple transport channels in the downstream mode for the same service. If the channel being used for upstream communication supports the downstream mode for the same service, then the server selects that channel for downstream work as well.
Default transport channels
Kaa provides four default transport channels that cover data exchange needs of all the Kaa services. Each channel is characterized by a transport protocol, type of server, transfer mode (upstream, downstream, or bi-directional), and one or multiple services. The default channels available together with Kaa are as follows:
|Channel name||Target server||Services||Supported modes||Based on|
|Default bootstrap||Bootstrap||Bootstrap||Bi-directional||HTTP 1.1|
|Default operation long poll||Operations||All except bootstrap||Bi-directional for profiling, configuration, notifications, and user association. Downstream for events and logs.||HTTP 1.1 long poll|
|Default operation HTTP||Operations||Events, logging||Upstream for events and logs.||HTTP 1.1|
|Default KaaTCP channel||Operations||All except bootstrap||Bi-directional||mqtt v3.1|
If a custom channel is created for upstream work with any service, then Kaa will always use the custom channel for the respective service, as the custom channel is a more recent one.