CN114900453B - 在不同客户端之间下发音频监听指令的物联网式解决方法 - Google Patents

Abstract

本发明属于计算机信息处理领域，具体是不同客户端之间下发音频监听指令的物联网式解决方法，步骤为：云服务器和机器端服务器在启动时，每台服务器注册MQTT服务；服务器收到客户端的请求后，在内存数据库添加监听位点的心跳，同时将指令主题发送给MQTT服务器；MQTT服务器向已经注册该主题的机器推送该指令，机器更新机器端服务器的全局变量，该全局变量为一个数组，每个元素为当前监听的位点，机器端服务器获取该位点的音频数据，并向数据主题推送原始的音频信息。本发明有一整套完备的逻辑，解决在不同的客户端需要对同一台主机设备发送同一条指令，但客户端后续的操作流程及逻辑不同时，如何兼容维护多种指令的并行及状态控制。

Description

在不同客户端之间下发音频监听指令的物联网式解决方法

技术领域

本发明属于计算机信息处理领域，具体是一种在不同客户端之间下发音频监听指令的物联网式解决方法。

背景技术

目前的服务器-客户端之间网络通信模式大部分都是HTTP请求模式，客户端和服务器端之间关系是不对等的，服务器端只用来提供服务，客户端只提出服务请求，即服务器端不可能主动联系某一个客户端，对其发送数据或者相关指令。目前普遍的解决方式是通过Websocket长链接方式在服务端和客户端之间建立长链接，服务器端保存与特定客户端的链接，在需要主动推送数据的时候，找到保存的链接，向客户端推送数据或者指令。

建立Websocket服务要求前后端都同时启动服务，对前端开发者，往往要具备数据驱动使用javascript的能力，且需要维持住Websocket连接（否则消息无法推送）。对后端开发者而言，难度增大了很多，一是长连接需要后端处理业务的代码更稳定，当并发数量过大时，后端需要对每一个链接进行管理，在推送消息时需要主动从服务器保存的Websocket链接列表中获取需要推送的客户端的连接，并且要确认客户端的链接是否仍然在线，以及推送的目标链接和发送链接是否匹配的问题，可能存在消息漏发或者误发的可能性。

发明内容

为解决现有技术存在的上述问题，本发明的目的在于提供一种基于多服务器与多客户端之间的指令及数据的下发方式及逻辑流程，解决目前在客户端与服务器之间定向下发指令时遇到的状态及逻辑问题，以及解决在遇到相同指令，但后续流程及逻辑不同时，如何兼容维护多种指令的并行及状态控制。

为实现上述技术效果，本发明的技术方案如下：

在不同客户端之间下发音频监听指令的物联网式解决方法，具体步骤包括：

步骤一，云服务器和机器端服务器在启动时，每台服务器使用唯一的ClientId去注册MQTT服务，云服务器启动服务时注册接收数据主题，机器端服务器启动时注册接收指令的主题，随后进入等待状态，当客户端在调用该指令时，注册MQTT服务，并订阅接收数据主题；

步骤二，当网页页面开始需要监听某个位点的音频时，首先向云服务器发送请求，服务器收到客户端的请求后，首先会在数据库记录该操作类型和状态，并在内存数据库添加监听位点的心跳，同时将指令主题发送给MQTT服务器；

步骤三，由于机器端服务器已经注册了该主题，当MQTT服务器收到指令主题后，则会向已经注册该主题的机器推送该指令，当机器接收到指令后，更新机器端服务器的全局变量，该全局变量为一个数组，每个元素为当前监听的位点，当机器端服务器的程序读取到该数组时，循环数组获取每个元素，去获取该位点的音频数据，并向数据主题推送原始的音频信息。

数组是用来存放元素的一个软件数据结构，元素可以有多个；一开始数组没有任何元素，在本次通信中，元素由机器服务器获取到指令主题推送来的消息后，根据消息中携带的数据添加进数组，该数据就是元素。

获取到每个元素后，机器即可根据时间间隔采集每个点位原始光信号，光信号传到探测器后转换为电信号，发送给采集卡，采集卡收到数据后发送给底层算法，由底层算法解出相关振动频率，还原为声音。

推送原始的音频信息是指机器端服务器通过数据主题推送给MQTT服务器，随后MQTT服务器会将数据推送给订阅该主题的客户端。

进一步地，流程中每个通信设备（服务器/客户端）在启动时都在MQTT服务器注册服务，并根据自己的业务逻辑订阅相关的音频数据主题，当主服务器的该主题收到信息后，则会主动向已经订阅该主题的客户端主动推送该信息。

进一步地，该方法中为保证在每个设备都能收到相关信息，在订阅该主题时有全路径匹配和正则匹配两种模式，当某个客户端需要对多个次级子主题订阅时，只需要订阅一次主要主题，并以通配符”#”对子主题进行订阅，当MQTT服务器收到任意一个客户端发来的子主题数据，则会将数据推送给订阅该主题的客户端。

进一步地，云服务器收到监听请求后，会将每次的监听位点放入一个数组列表，并将该数组列表通过MQTT的主题推送给相关的主机服务器，主机通过订阅的主题收到指令后，会更新全局的监听列表，在采集音频的逻辑中，获取每一个位点的音频，最后通过每个不同点位生成子主题，发送到MQTT服务器，订阅了该位点的客户端收到音频数据后，按顺序进行播放。

本发明的优点在于：

1、本发明与现有技术的最大区别在于有一整套完备的发送指令---转发指令----维护状态----定期检测----数据交互的逻辑，这套方法的目的在于提供一种基于多服务器多主机与多客户端之间的指令及数据的交互方式及逻辑流程，以及解决在不同的客户端需要对同一台主机设备发送同一条指令，但客户端后续的操作流程及逻辑不同时，如何兼容维护多种指令的并行及状态控制。

2、本发明解决了主机无法主动向客户端发送消息的问题；保证了客户端监听位点与收到的音频来源一致性和唯一性，防止不同客户端收到错误音频。

3、客户端收到音频后会发送上报信息增加心跳，保证了后续音频获取的连续性。

4、主机服务器收到的列表为全量更新，不需要主机方对每个位点进行状态判断，让主机的程序可以纯粹的获取音频数据。

附图说明

图1为音频监听指令的流通过程示意图。

图2为音频数据的流通及心跳维持过程示意图。

具体实施方式

为了更好的理解上述技术方案，下面将结合附图通过具体实施例进行进一步的说明，需要注意的是本发明技术方案包括但不限于一下实施例。

实施例1

在不同客户端之间下发音频监听指令的物联网式解决方法具体步骤包括：

步骤一，云服务器和机器端服务器在启动时，每台服务器使用唯一的ClientId去注册MQTT服务，云服务器启动服务时注册接收数据主题，机器端服务器启动时注册接收指令的主题，随后进入等待状态，当客户端在调用该指令时，注册MQTT服务，并订阅接收数据主题；这是在监听音频前需要做的一系列初始化和注册的方法。其中云服务器和机器端服务器在针对我方的客户端时是作为服务器，在针对MQTT服务器的时候是作为客户端注册。

数据主题是MQTT通讯中的一部分，用于收发数据，数据主题的内容是本次通讯中，用于上报或收取音频原始信息。

接收指令的主题是我方客户端下发监听指令需要涉及的主题。

步骤二，当网页页面开始需要监听某个位点的音频时，首先向云服务器发送请求(Http请求)，服务器收到客户端的请求后，首先会在数据库记录该操作类型和状态，并在内存数据库添加监听位点的心跳，同时将指令主题发送给MQTT服务器；

软件中某些操作需要维持一段时间，就需要加入心跳机制来维持该操作的状态，当心跳存在时，操作继续进行，当心跳消失后，操作则停止。

本次系统涉及四个角色：MQTT服务器，机器端服务器，云服务器，用户客户端（即网页）。

步骤三，由于机器端服务器已经注册了该主题，当MQTT服务器收到指令主题后，则会向已经注册该主题的机器推送该指令，当机器接收到指令后，更新机器端服务器的全局变量，该全局变量为一个数组，每个元素为当前监听的位点，当机器端服务器的程序读取到该数组时，循环数组获取每个元素，去获取该位点的音频数据，并向数据主题推送原始的音频信息。

数组是用来存放元素的一个软件数据结构，元素可以有多个；一开始数组没有任何元素，在本次通信中，元素由机器服务器获取到指令主题推送来的消息后，根据消息中携带的数据添加进数组，该数据就是元素。

循环获取元素具体是指采用编程语言中的循环读取数组的for方法，只要在程序中调用该方法，程序就可以按照数组中的元素顺序去读取每一个元素。

获取到每个元素后，机器即可根据时间间隔采集每个点位原始光信号，光信号传到探测器后转换为电信号，发送给采集卡，采集卡收到数据后发送给底层算法，由底层算法解出相关振动频率，还原为声音。这里提到的底层算法可以为本领域技术人员公知的算法。

推送原始的音频信息是指机器端服务器通过数据主题推送给MQTT服务器，随后MQTT服务器会将数据推送给订阅该主题的客户端。

进一步地，流程中每个通信设备（服务器/客户端）在启动时都在MQTT服务器注册服务，并根据自己的业务逻辑订阅相关的音频数据主题，当主服务器的该主题收到信息后，则会主动向已经订阅该主题的客户端主动推送该信息。

进一步地，该方法中为保证在每个设备都能收到相关信息，在订阅该主题时有全路径匹配和正则匹配两种模式，当某个客户端需要对多个次级子主题订阅时，只需要订阅一次主要主题，并以通配符”#”对子主题进行订阅，当MQTT服务器收到任意一个客户端发来的子主题数据，则会将数据推送给订阅该主题的客户端。

进一步地，云服务器收到监听请求后，会将每次的监听位点放入一个数组列表，并将该数组列表通过MQTT的主题推送给相关的主机服务器，主机通过订阅的主题收到指令后，会更新全局的监听列表，在采集音频的逻辑中，获取每一个位点的音频，最后通过每个不同点位生成子主题，发送到MQTT服务器，订阅了该位点的客户端收到音频数据后，按顺序进行播放。

实施例2

音频监听指令的流通过程:

1）云服务器，主机服务器启动时注册MQTT服务，并且主机服务器订阅音频监听相关的主题，云服务器根据通配符订阅音频数据相关子主题；

2）客户端在登录时，获取当前账号所配对的设备Id，并且注册MQTT服务；

3）客户端在监听时，先将监听位点及主机Id发送给云服务器，同时订阅该主机及位点的主题，等待接收音频数据；

4）云服务器收到客户端发来的监听请求及位点，设备信息，首先将信息添加一条监听心跳，存入数据库，随后组装监听指令及主题，发送给MQTT服务器。

云服务器在收到请求后，拼装出主题，准备向MQTT服务器发送数据。

Device_wave/order/{DeviceId}

其中，客户端与服务器之间通过MQTT服务器发送指令，发送数据格式采用统一的格式封装，所定义的数据报文封装格式如表一所示：

表1 监听请求数据包封装格式

表1中，DeviceId表示需要监听的设备Id ，当主机收到DistanceList表示监听位点的列表，Status表示监听的状态，From表示请求的来源方。

实施例3

主机服务器发送的音频数据结构

当主机在程序中采集到点位的音频后，则会组装音频数据，准备向MQTT服务器发送数据，进行下一步的数据推送。

1）主机服务器收到主题发送的监听请求后，更新全局监听列表，并在程序中获取该列表的所有位点的音频，并组装数据主题，将对应的音频数据发送给MQTT服务器；

2）由于客户端和云服务器订阅了主题，当MQTT服务器收到音频数据后，则会向客户端和云服务器推送相关的数据；

3）客户端每次收到音频数据后，会向云服务器发送上报信息，服务器收到后，会对数据库中的监听心跳进行续写，保证主机服务器能一直采集该位点的音频，云服务器收到音频文件后，则将音频数据组装，以文件的方式保存；

4）当客户端主动停止监听，或者页面被关掉，则停止给云服务器发送上报信息，云服务器上的心跳停止，由云服务器上的定时任务进行检查，当发现心跳的时间距离当前时间超过了设置的范围后，则从监听列表里剔除该位点，并将新的监听列表信息发送给MQTT服务器。

首先在服务器上组装需要发送的主题，按照以下格式拼装

Device_wave/data/D/{DeviceId}/d/{distance}

主机发送的数据遵循以下的数据结构:

表2 音频数据包封装格式

表2中， DeviceId表示发送该音频的设备ID， Distance表示监听的位点距离，DeviceID和Distance在发送的主题中也有体现，再次传输该数据，用于客户端可以二次确认收到的数据来自正确的机器和正确的监听位点。

SendTime表示发送数据的时间戳，客户端在播放音频时，可以用作日志展示使用，以确保收到的音频数据是连续且顺序无误的。

Wave则是发送的原始音频文件，WaveRate表示该音频在机器上的采样率，客户端在收到后可以根据采样率拼接出原始的Wave文件头，并将Wave原始数据添加到文件头后面，调用页面的播放器进行播放。

Claims (7)

1.在不同客户端之间下发音频监听指令的物联网式解决方法，其特征在于，具体步骤包括：

步骤一，云服务器和机器端服务器在启动时，每台服务器使用唯一的ClientId去注册MQTT服务，云服务器启动服务时注册接收数据主题，机器端服务器启动时注册接收指令的主题，随后进入等待状态，当客户端在调用该音频监听指令时，注册MQTT服务，并订阅接收数据主题；

步骤二，当网页页面开始需要监听某个位点的音频时，首先向云服务器发送请求，云服务器收到客户端的请求后，首先会在数据库记录下发音频监听指令的类型和状态，并在内存数据库添加监听位点的心跳，同时将指令主题发送给MQTT服务器；

步骤三，由于机器端服务器已经注册了该接收指令的主题，当MQTT服务器收到指令主题后，则会向已经注册该接收指令的主题的机器端服务器推送该音频监听指令，当机器端服务器接收到指令后，更新机器端服务器的全局变量，该全局变量为一个数组，每个元素为当前监听的位点，当机器端服务器的程序读取到该数组时，循环数组获取每个元素，去获取该位点的音频数据，并向数据主题推送原始的音频信息。

2.根据权利要求1所述的在不同客户端之间下发音频监听指令的物联网式解决方法，其特征在于，数组是用来存放元素的一个软件数据结构，元素有多个；一开始数组没有任何元素，在本次通信中，元素由机器端服务器获取到指令主题推送来的消息后，根据消息中携带的数据添加进数组，该数据就是元素。

3.根据权利要求2所述的在不同客户端之间下发音频监听指令的物联网式解决方法，其特征在于，获取到每个元素后，机器端服务器根据时间间隔采集每个位点原始光信号，光信号传到探测器后转换为电信号，发送给采集卡，采集卡收到数据后发送给底层算法，由底层算法解出相关振动频率，还原为声音。

4.根据权利要求1所述的在不同客户端之间下发音频监听指令的物联网式解决方法，其特征在于，推送原始的音频信息是指机器端服务器通过数据主题将原始的音频信息推送给MQTT服务器，随后MQTT服务器会将数据推送给订阅该数据主题的客户端。

5.根据权利要求1所述的在不同客户端之间下发音频监听指令的物联网式解决方法，其特征在于，流程中每个通信设备在启动时都在MQTT服务器注册服务，并根据自己的业务逻辑订阅相关的数据主题，当MQTT服务器收到信息后，则会主动向已经订阅相关的数据主题的客户端主动推送该信息。

6.根据权利要求1所述的在不同客户端之间下发音频监听指令的物联网式解决方法，其特征在于，该方法中为保证在每个通信设备都能收到相关信息，在订阅主题时有全路径匹配和正则匹配两种模式，当某个客户端需要对多个次级子主题订阅时，只需要订阅一次主要主题，并以通配符”#”对子主题进行订阅，当MQTT服务器收到任意一个客户端发来的子主题数据，则会将数据推送给订阅主题的客户端。

7.根据权利要求1所述的在不同客户端之间下发音频监听指令的物联网式解决方法，其特征在于，云服务器收到监听请求后，会将每次的监听位点放入一个数组列表，并将该数组列表通过MQTT的主题推送给相关的机器端服务器，机器端服务器通过订阅的主题收到指令后，会更新全局的监听列表，在采集音频的逻辑中，获取每一个位点的音频，最后通过每个不同位点生成子主题，发送到MQTT服务器，订阅了该位点的客户端收到音频数据后，按顺序进行播放。