10.1. It’s just a piece of cake

Client management operations are performed in the CLIENT MANAGEMENT panel. Clicking the “clients” button opens the manager:

Here is a client manager for the demo site “Surveillance System”:

Client entities are displayed in the “clients” section. It contains a two-level list, where the first level consists of users authorized on the site, and the second level consists of clients associated with users of the first level and inheriting their access rights. To the right of each user, except for the Contact users, there is an “add client” button, clicking on which adds a new client associated with this user.

In the image below, a client is added for GuardPost:

Let’s generate a password and connect a client application to the site. After the first connection of the client app, the client entity looks like this:

Typically, a client is represented on the site by a client key and client description. The client key is created by the site, but the client description is provided by the client itself. The latter is optional but highly desirable parameter. It usually contains the functional description of the client and its version, which helps the owner in administrative tasks. In case of our example, the client is represented by:

client key: k1uckqabs
description: Cold Vision Monitor. V: 1.0.2

GuardPost has been assigned the Operator and User roles, so the client application will interact with the IP cameras in accondance with these roles.

There can be multiple clients on the site associated with a user. In the following image, the second client “Cold Vision Remote Control. V: 2.2.1” is set up for GuardPost user:

To the left of each client entity, except for the clients of Contact users, there is a “>>” button, clicking on which opens the client editor:

The client editor contains two menu buttons. The first button “account” provides the account information used to connect a client app. The second button “ping period” allows you to set the ping period. So what is the client ping period? Its purpose is similar to that discussed in the “Ping Period” section for a service application. If the device hosting your client application is highly mobile, it may change its IP address quite often. And when it happens, the client app is unable to receive events from the Softnet platform until the app detects that the device’s address is changed and re-establishes the control channel. Depending on the underlying platform, the time required to detect a broken control channel can vary quite widely. However, using the Ping Period parameter, you can tune this time as you need. The Ping Period is the amount of time to wait between ping messages that the client app on the device sends to the site. If the ping message is not responded within a certain period of time, the control channel is considered as broken, and the client app re-establishes the control channel.

Clicking the “ping period” button opens the Ping Period editor:

By default, the Ping Period is 300 seconds (5 minutes). The developer or the device user can set a specific ping period on the device, or leave it at the default value by specifying 0. The Ping Period can also be set here on the management panel. If you specify a value between 10 secondts and 300 seconds, it will overwrite the value set on the device. However, if you specify 0, the Ping Period will be set to the device’s local value, or to the default value of 300 seconds if the device’s local value is also 0.

In the image below, the ping period is set to 30 seconds. It is shown as “P: 30”:

Client applications you connect to the site must be designed to consume the service set up on the site. As you know, the service interface is denoted by the names of <Service Type> (<Contract Author>). When a client app connects to the site, it provides the site with the names of <Service Type> (<Contract Author>) of the interface for which it is designed. If they are not identical to what the site expects, the client will be assigned the status “service type conflict” and blocked. If you encounter this error, just disconnect the wrong client and connect the right one.

For example, the image below demonstrates such a scenario. A client designed for the interface NightVision-FX5 (Avalon) is connected to the site built for the service interface RTX-5 (Cold Vision):

In case of the “service type conflict” error, the client entity shows in red the <Service Type> (<Contract Author>) for which the client is designed.