How to efficiently detect the running status of DECService?

[streetycat]

In most time, the client will run depend on the service, the service should also running always.

But, I can not ensure that the service will always run normally. the state will be changed frequently at least while the App is installing at least.

So. I want to detect the state immediatly.

Currently, I usually provide a ping interface on the service. But there are several disadvantages:

• The timer is not real-time.
• It will bring more additional burden when there are many Apps.

[lurenpluto]

About how the client detects the existence of service, in fact, belongs to a very common problem, is the client to the service of the specified event subscription mechanism, such as service start, key state change, in general can be the following two practices

1. Based on polling

The client polls the service for a state based on a time interval. This is basically foolproof, but there are obvious disadvantages, such as the design of the polling interval, and the performance problems caused by frequent polling.

2. Based on sub-pub mechanism

From the service's point of view, a better approach is to provide a subscribe-publish mechanism, so that clients can subscribe to the events of interest and be notified of the subscribed clients after the start of the dec service and state change; the sub-pub mechanism can be based on OOD's root-state+post-object design. object to expand the design

[streetycat]

It is a good idea to provide a unified publish and subscribe component in the system.

In this way, resources can be coordinated in a unified manner to avoid waste of resources caused by polling by each client.

But, exceptions for client missing events will be hard to handle.

Maybe, We can make a unified polling mechanism at the system level to synchronize the subscribed status regularly.

[lurenpluto]

sub-pub system can not guarantee that the client will not miss the event, generally with the active query mechanism to achieve, but sub-pub module should be more pure, do not need to think too much about these cases

[lurenpluto]

From a more general perspective, a subscribe-publish notification event system can be designed based on root-state and post-object

Some key points of sub-pub should be these:

Publisher

Initiated by dec service, running on OOD

Subscriber

Initiated by each client of the dec, can support cross-zone, cross-dec
For example, in your requirement, the typical client is on the web side, so it is initiated by the web page, based on the device identity of cyfs-runtime to the OOD corresponding dec service to initiate the subscription operation

Channel

The publisher follows a predesigned root-state path, such as
/notify/{channel}, where the leaf node can use the following (key, value) pattern

• Key The device-id of the subscriber
• Value The corresponding subscription parameters, which depend on the channel configuration, in some cases include the following options
  o Subscriber identity information, usually including at least device(zone) and dec information
  o Callback path, the subscriber (web side) needs to listen to the post-object (call) events on this path in the local runtime
  o The configuration of the event, such as whether the trigger mode is single trigger or multiple trigger, the retry mechanism after trigger failure, etc.

Subscribe process

The client can subscribe to the channel of interest to the dec service
If it is within the zone, then the client can directly modify the root-state channel on ood, which is the simplest and most direct way, but only for simple sub-pub services, such as an app's web page and simple notifications within the dec service

In a complete sub-pub system, subscribers generally do not modify the root-state of OOD directly, but should call the interface of the dec service (via post-object) to perform operations such as subscribing and unsubscribing, which means that a set of API needs to be designed to better support the pub-sub service

Publish process

After the dec service starts or when the state changes, it reads all the subscriber information under the path of the channel that needs to be pub, either by using a list or enumeration mechanism, and then according to the subscription information, it generally includes the following key information

• Dec
  Can be limited to the same dec to subscribe, or support cross-dec subscription
• Device
• Can be qualified to subscribe to the same zone, or support cross-zone subscription
• callback path
  Use to post-object
• Config
  The specific configuration of the subscriber, such as whether it is a single trigger or multiple triggers, some additional parameters for the callback, etc., depends on the specific design of the sub-pub system.

After the Dec service gets the above information, it constructs a channel-specific object and posts to the path, either serially or concurrently, and whether it needs to handle the subscriber's response, etc.