# 命令下发结构

## 1. 服务器端和边缘主机采用websocket协议通讯

## 2. 下发的数据格式如下
    <<T:1byte, Body:任意长度(先json序列化，然后aes加密)>>, 其中

    "t": 1|2|3|4,
    Body: 

        ```json
        {	
            // 针对不同的命令类型，这个字段里的`to`和`m`数据有所不同，具体在下面的小节描述
            // 任务id，服务端在下发数据的时候，需要生成一个唯一的uuid，
            // 用于标识一个任务
            "t_id": "任务id",
            // 表示发给哪个微服务，这里是服务的标识，即服务名称
            "to":  "",
            // 命令执行的超时时间，单位为秒
            "t": 10,
            // 实际内容
            "m": "$bytes",
        }
        ```
## 3. 加密前的消息结构如下：
    消息类型，目前支持四种消息类型:
    * 1代表参数下发，就是向该设备端的微服务发送消息,该消息会辗转发送给微服务进行处理，比如，设置modbus微服务的波特率等消息
    * 2代表采集向下发，比如，设置某个设备短上的modbus微服务采集某个地址的数据
    * 3代表下发微服务文件。
    * 4代表下发数据流图，这个指令用于设置设备端上各个微服务之间的逐句流转。 

### 3.1 参数下发的结构
    对于参数下发，下发内容中的m为一个`map[string]interface{}`结构，用于向某个微服务发送参数，具体参数内容由微服务的参数配置提供。

### 3.2 微服务的启动和停止
    微服务的启动和停止由内置服务`service-monitor`管理，所以，实际启动和停止，只需要给该服务发送参数就行，其他流程（返回的step和result等）保持一致。实际下发的结构为：

    ```json
    {	
        // 针对不同的命令类型，这个字段里的`to`和`m`数据有所不同，具体在下面的小节描述
        // 任务id，服务端在下发数据的时候，需要生成一个唯一的uuid，
        // 用于标识一个任务
        "t_id": "任务id",
        // 表示发给哪个微服务，启动和停止，都是发给内置服务service-monitor
        "to":  "service-monitor",
        // 命令执行的超时时间，单位为秒
        "t": 10,
        // 实际内容
        "m": {
            "service_name": "需要启动或者停止的服务名， ${name}${copy}-${version}的格式",
            "action": "start|stop",
            "command": "如果是start，则需要传递启动命令，启动命令由config.yaml配置文件的boot字段指定"
        }
    }

    ```

### 3.3 采集项下发的结构
    采集项下发时，下发内容中的m为一个`[]map[string]interface{}`结构的列表，每一个条目是一个采集项内容，具体采集向内容由微服务的采集项配置提供。

### 3.4 微服务下发的结构
    在微服务下发中，`to`字段会被忽略，可以填写空字符串，而m字段为json化之后的数据，json化之前结构如下：

    ```json
    {
        "f": "微服务名",
        "v": "微服务版本"
        "k": "微服务下载的token"
        "md5": "微服务的md5值，用于验证下载完整性"
        // ms表示是微服务，config表示配置文件，self表示efka的新版本
        "t": "ms|config|self"
        // o代表oldversion，老版本，如果t为ms，且o不为空字符串，
        // 则表示要升级微服务版本，老版本的内容会被删除和替换。
        "o": "old-version"
    }
    ```