CN113055640B - 一种监控系统内设备管理方法及装置 - Google Patents

Abstract

本发明公开了一种监控系统内设备管理方法及装置，将组网内所有前端设备进行分级，第二级设备接收第三级设备的注册请求，建立与第三级设备的管辖关系，管辖所述第三级设备；第二级设备还接收第三级设备的保活信息，更新第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息；向第一级设备发送注册请求，建立与第一级设备的管辖关系，被所述第一级设备所管辖，并向所述第一级设备发送保活信息。本发明通过逐级管辖，大幅的降低了中心服务器的性能压力。

Description

一种监控系统内设备管理方法及装置

技术领域

本发明属于设备注册管理技术领域，尤其涉及一种监控系统内设备管理方法及装置。

背景技术

视频监控是安全防范系统的重要组成部分，视频监控以其直观、准确、及时和信息内容丰富而广泛应用于许多场合。近年来，随着计算机、网络以及图像处理、传输技术的飞速发展，视频监控的普及化趋势越来越明显。

视频监控系统中，视频管理服务器VM是监控系统业务控制和管理的核心，负责业务的信令交互和调度，管理整个系统的设备信息和用户信息，是整个监控系统的指挥中心。网络摄像机IPC是分布在各个地点的前端设备，负责收集实时图像。原则上IPC需要向视频管理服务器VM注册，并接受视频管理服务器VM的管理和配置。前端设备IPC通过IP网络直连到中心服务器VM(视频管理服务器)上，通过IPC主动发送SIP协议消息进行注册和保活，用于向VM同步设备当前的状态。VM也可通过主动发送SIP协议消息来下发配置和请求。

这种IPC与VM直连的拓扑结构，当IPC的数量较多，达到十万路、百万路甚至更多的时候，VM服务器的性能压力就会捉襟见肘。以100万个IPC需30秒保活一次为例，VM平均1秒内需要正确处理3.3万个设备的保活才能保证功能正常，平均1条请求0.03毫秒，这还不计其他的设备配置、实时监控、媒体流控制等消息，一般的服务器无法达到该效率，需要更高性能的设备，导致设备的成本上升。此外，当中心服务器VM异常时，所有前端设备由于无法访问服务器而瘫痪，无法继续进行业务。

发明内容

本发明的目的是提供一种监控系统内设备管理方法及装置，用于避免背景技术中提出的向中心服务器直接进行注册和保活的种种弊端。

为了实现上述目的，本申请技术方案如下：

一种监控系统内设备管理方法，所述监控系统内设备管理方法，应用于第二级设备，包括：

接收第三级设备的注册请求，建立与第三级设备的管辖关系，管辖所述第三级设备；

接收第三级设备的保活信息，更新第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息；

向第一级设备发送注册请求，建立与第一级设备的管辖关系，被所述第一级设备所管辖；

向所述第一级设备发送保活信息，以便第一级设备更新本第二级设备的设备信息以及注册保活在本第二级设备上设备的设备信息。

进一步的，所述接收第三级设备的注册请求，建立与第三级设备的管辖关系；向第一级设备发送注册请求，建立与第一级设备的管辖关系，包括：

通过第一组播地址和端口向第一级设备发送发现请求，并接收所述第一级设备的响应消息，回复应答消息，建立与所述第一级设备的管辖关系，向所述第一级设备进行注册保活；

通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息；

通过第二组播地址和端口接收所管辖的第三级设备的注册保活消息。

进一步的，所述通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息，包括：

通过第二组播地址和端口接收第三级设备的发现请求；

判断自身是否还有负载能力来管辖所述第三级设备，如果有则向所述第三级设备发送响应消息。

进一步的，所述接收所述第一级设备的响应消息，回复应答消息，包括：

所述响应消息中携带所述第一级设备的负载能力信息；

在接收到所述第一级设备的响应消息后，根据所述第一级设备的负载能力，判断是否选择所述第一级设备来管辖，向所选择的第一级设备回复应答消息。

进一步的，所述设备信息包括：所述第三级设备的状态信息、以及注册保活在所述第三级设备上设备的状态信息；所述第三级设备的层级信息、以及注册保活在所述第三级设备上设备的层级信息；

所述监控系统内设备管理方法，还包括：

根据第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息，建立设备映射表，在接收第一级设备转发的配置以及查询消息时，根据建立的设备映射表进行转发。

本申请还提出了一种监控系统内设备管理装置，所述监控系统内设备管理装置，应用于第二级设备，包括：

下级管理模块，用于接收第三级设备的注册请求，建立与第三级设备的管辖关系，管辖所述第三级设备；接收第三级设备的保活信息，更新第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息；

上级注册保活模块，用于向第一级设备发送注册请求，建立与第一级设备的管辖关系，被所述第一级设备所管辖；向所述第一级设备发送保活信息，以便第一级设备更新本第二级设备的设备信息以及注册保活在本第二级设备上设备的设备信息。

进一步的，所述下级管理模块在接收第三级设备的注册请求，建立与第三级设备的管辖关系时，执行如下操作：

通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息；

通过第二组播地址和端口接收所管辖的第三级设备的注册保活消息。

所述上级注册保活模块在向第一级设备发送注册请求，建立与第一级设备的管辖关系时，执行如下操作：

通过第一组播地址和端口向第一级设备发送发现请求，并接收所述第一级设备的响应消息，回复应答消息，建立与所述第一级设备的管辖关系，向所述第一级设备进行注册保活。

进一步的，所述下级管理模块通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息，执行如下操作：

通过第二组播地址和端口接收第三级设备的发现请求；

判断自身是否还有负载能力来管辖所述第三级设备，如果有则向所述第三级设备发送响应消息。

进一步的，所述上级注册保活模块接收所述第一级设备的响应消息，回复应答消息，执行如下操作：

所述响应消息中携带所述第一级设备的负载能力信息；

在接收到所述第一级设备的响应消息后，根据所述第一级设备的负载能力，判断是否选择所述第一级设备来管辖，向所选择的第一级设备回复应答消息。

进一步的，所述设备信息包括：所述第三级设备的状态信息、以及注册保活在所述第三级设备上设备的状态信息；所述第三级设备的层级信息、以及注册保活在所述第三级设备上设备的层级信息；

所述监控系统内设备管理装置，还包括：

转发模块，用于根据第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息，建立设备映射表，在接收第一级设备转发的配置以及查询消息时，根据建立的设备映射表进行转发。

本申请提出的一种监控系统内设备管理方法及装置，每台前端设备IPC既作为终端设备完成业务，也可作为网状结构上的一个服务器，大幅的降低了中心服务器的性能压力。通过组播，实现自动设备发现，自发形成自治系统，无需对主从设备间关系进行详细配置。

附图说明

图1为本发明实施例监控系统内设备管理方法流程图；

图2为本发明实施例设备分级层次示意图；

图3为本发明实施例设备管辖关系示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅用以解释本申请，并不用于限定本申请。

本申请提供的一种监控系统内设备管理方法，总体思路是取消所有前端设备IPC都向中心服务器VM发送注册保活的方式，将组网内所有前端设备IPC进行分级，级数由前端设备IPC个数决定，设备较多时可分多级以保证效率和稳定。本申请不限于具体的分级方法，例如可以按照地理位置来分级，靠近中心服务器VM的级别高，越边缘的级别越低；也可以按照区域的行政级别来分，市级的级别高，县级的级别低；或者按照距离中心服务器VM的路由跳数来分，跳数少的级别高，跳数多的级别低；或者有管理人员人为来分级。关于分级的具体方法，这里不一一赘述。

级间通过组播实现设备的自动发现，即上下两级设备加入同一组播地址，上级设备在收到下级设备的搜索信令后，根据自身的负载均衡，做出是否管辖该设备的响应。在管辖关系确定后，第三级前端设备IPC启动时，向第二级前端设备发送REGISTER信令，第二级前端设备IPC收到该注册信令后，在第二级前端设备IPC的下一个保活信令中，向第一级前端设备IPC汇报新注册的第一级前端设备IPC。第一级前端设备IPC记录第三级前端设备IPC的路由为通过第二级前端设备IPC。以此类推，最终将上报至中心服务器VM。

在一个实施例中，如图1所示，一种监控系统内设备管理方法，应用于第二级设备，包括：

接收第三级设备的注册请求，建立与第三级设备的管辖关系，管辖所述第三级设备；

接收第三级设备的保活信息，更新第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息；

向第一级设备发送注册请求，建立与第一级设备的管辖关系，被所述第一级设备所管辖；

向所述第一级设备发送保活信息，以便第一级设备更新本第二级设备的设备信息以及注册保活在本第二级设备上设备的设备信息。

具体的，本申请将组网内所有前端设备IPC进行分级，级数由前端设备IPC个数决定，设备较多时可分多级以保证效率和稳定。如图2所示，本申请以四层为例，对于更多层级同样适用。本实施例以第二级设备为例进行说明，其中第一级设备是其上级设备，第三级设备是其下级设备，第四级设备为第三级设备的下级设备。

本申请中，第二级设备接收第三级设备的注册请求，建立与第三级设备的管辖关系；向第一级设备发送注册请求，建立与第一级设备的管辖关系。可以采用多种方式来建立管辖关系，例如本申请上下级之间的管辖关系可以通过组播来进行自发形成自治系统，还可以通过手动进行设备层级规划，在下级设备上配置上级设备IP，通过直接网络连接的方法进行配置。也可以通过网关进行配置，可以将上述组播发现的流程交由网关进行，网关感知到IPC在进行网络搜索时，规划得到各IPC之间的关系，下发相应配置。

以下以组播为例进行说明：

通过第一组播地址和端口向第一级设备发送发现请求，并接收所述第一级设备的响应消息，回复应答消息，建立与所述第一级设备的管辖关系，向所述第一级设备进行注册保活；

通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息；

通过第二组播地址和端口接收所管辖的第三级设备的注册保活消息。

本实施例，级间通过组播实现设备的自动发现，即上下两级设备加入同一组播地址，上级设备在收到下级设备的搜索信令后，根据自身的负载均衡，做出是否管辖该设备的响应。

即每一级设备拥有一个独立的组播地址和端口，用于该级所有设备主动发现上级设备，在本实施例中称为第一组播地址和端口。一台设备需要配置本层级的第一组播地址和端口，还需要配置与其下级设备进行通信的第二组播地址和端口，配置第二组播地址和端口用于接收下级设备的发现请求和回复响应。

本实施例下级设备与其上级设备间确定管辖关系需要采用类似“三次握手”的方法确定。如下三步：

A.下级设备发送的组播地址的发现请求如下：

<？Xml version＝”1.0”？>

<Request>

<CmdType>GetUpper</CmdType>

<DeviceID>下级设备ID</DeviceID>

<SN>命令序列号</SN>

<Address>下级设备IP地址</Address>

</Request>

B.加入同一组播组的上级设备收到该请求后，检查自身是否还有能力管辖该设备，若能力足够，则向下级设备回复响应：

<？Xml version＝”1.0”？>

<Response>

<CmdType>GetUpper</CmdType>

<SN>命令序列号</SN>

<DeviceID>上级设备ID</DeviceID>

<Address>上级设备IP地址</Address>

</Response>

C.下级设备收到B响应后，回复成功ACK消息，记录上级设备的IP地址记录，后续向该IP进行注册保活。

<？Xml version＝”1.0”？>

<ACK>

<CmdType>GetUpper</CmdType>

<SN>命令序列号</SN>

<Result>Success</Result>

</ACK>

最后，上级设备收到成功的ACK消息后，记录下级设备的IP地址和设备ID。

以第二级设备为例来说，其与第一级设备是通过第一组播地址和端口通信，通过第一组播地址和端口向第一级设备发送发现请求，并接收第一级设备的响应消息，回复应答消息，建立与第一级设备的管辖关系。

同样，第三级设备为第二级设备的下级设备，第二级设备与第三级设备通过第二组播地址和端口进行通信，通过第二组播地址和端口接收第三级设备的发现请求，判断自身是否有能力管辖所述第三级设备，如果有则进行响应。

以此类推，第四级设备与第三级设备也以设定的组播地址和端口进行通信，第三级设备接收第四级设备的发现请求，判断自身是否有能力管辖所述第四级设备，如果有则进行响应。第四级设备接收到第三级设备的响应消息，回复应答消息，建立与第三级设备的管辖关系。至于更多的层级，基于上述方法都可以建立下级与上级的管辖关系，这里不再赘述。

在一个实施例中，所述通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息，包括：

通过第二组播地址和端口接收第三级设备的发现请求；

判断自身是否还有负载能力来管辖所述第三级设备，如果有则向所述第三级设备发送响应消息。

具体的，本申请上级设备收到下级设备的发现请求后，还需要判断自身是否还有负载能力来管辖该设备，若能力足够，则向下级设备回复响应，否则就拒绝响应，放弃管辖该下级设备。这样当下级设备向多个上级设备发送发现请求后，总能找到有能力管辖的上级设备，建立管辖关系，也实现了上级设备间的负载均衡。

在一个实施例中，所述接收所述第一级设备的响应消息，回复应答消息，包括：

所述响应消息中携带所述第一级设备的负载能力信息；

在接收到所述第一级设备的响应消息后，根据所述第一级设备的负载能力，判断是否选择所述第一级设备来管辖，向所选择的第一级设备回复应答消息。

具体的，下级设备在收到上级设备的响应消息后，根据所述响应消息中携带的上级设备的负载能力信息，下级设备可以根据上级设备的负载能力信息，选择是否对响应消息进行应答。此时下级设备可以选择负载能力剩余较大的上级设备进行应答，与其建立管辖关系，从而实现上级设备的负载均衡。也可以直接选择最先响应的、负载能力未超限的上级设备进行应答，与其建立管辖关系，对于负载能力超限的拒绝进行应答。

在建立管辖关系之后，第二级设备通过第二组播地址和端口接收所管辖的第三级设备的注册保活消息，所述注册保活消息携带第三级设备本身的设备信息以及注册保活在所述第三级设备上设备的设备信息。之后，第二级设备通过第一组播地址和端口向第一级设备进行注册保活，携带第二级设备的设备信息，以及注册保活在所述第二级设备上设备的设备信息。以此类推，最终将上报至中心服务器VM。

需要说明的是，下级设备在确定与上级设备的管辖关系后，首先进行注册，然后进行保活，本申请中统称为注册保活。

如图3所示，以每个父节点管理6个子节点为例，其中灰色六边形的每个顶点表示一个第三级设备，每个黑色六边形的顶点表示一个第二级设备。第三级设备分别向所在的三个六边形中央的第二级设备进行注册。本申请新增REGISTER消息的Body体，在DeviceList标签内填充该第三级设备及所有已向该第三级设备注册上线的设备。

消息格式如下：

REGISTER sip:2级设备ID@2级设备目的域名或IP地址端口SIP/2.0Via:SIP/2.0/UDP源域名或IP地址端口

From:<sip:3级设备ID@源域名>；tag＝e8ba7be

To:<sip:3级设备ID@源域名>

Call-ID:b139efe72339efe7c739efe71c39efe734@192.169.13.98

Contact:<sip:3级设备ID@源IP地址端口>

CSeq:1REGISTER

Max-Forwards:70

Expires:3600

Content-Length:消息实体的字节长度

<？Xml version＝”1.0”？>

<Notify>

<CmdType>Register</CmdType>

<SN>1</SN>

<DeviceList Num＝1>

<Item>

<DeviceID>3级设备ID</DeviceID>

</Item>

</DeviceList>

</Notify>

第二级设备收到上述注册请求，经过校验成功后，向第三级设备回复200OK响应。

第二级设备内部应维护一个设备映射表，标识下级设备的注册关系。当上级向下级下发配置时，应能正确找到对应的信令IP地址进行信令转发。如表1所示：

表1设备映射表

第三级设备收到第二级设备回复的200OK后，即自认为注册成功。

之后每隔30秒向第二级设备发送保活请求，消息格式如下：

MESSAGE sip:2级设备ID@2级设备目的域名或IP地址端口SIP/2.0Via:SIP/2.0/UDP源域名或IP地址端口

From:<sip:3级设备ID@源域名>；tag＝e8ba7be

To:<sip:2级设备ID@源域名>

Call-ID:36f58517a4f5851740f585179bf58517b3@192.169.13.98

Contact:<sip:3级设备ID@源IP地址端口>

CSeq:2MESSAGE

Max-Forwards:70

Content-Type:Application/MANSCDP+xml

Content-Length:消息实体的字节长度

<？Xml version＝”1.0”？>

<Notify>

<CmdType>KeepAlive</CmdType>>

<SN>2</SN>

<DeviceID>3级设备ID</DeviceID>

<DeviceList Num＝0>

</DeviceList>

</Notify>

容易理解的是，下级设备向上级设备注册，确定了相互之间的管辖关系之后，还需要定期进行保活，从而更新下级设备在上级设备上的设备信息。一般来说，设备信息需要包括设备ID、设备名称、设备IP地址等，本申请还具有以下实施例：

在一个实施例中，所述设备信息还携带所述第三级设备的状态信息、以及注册保活在所述第三级设备上设备的状态信息。

在另一个实施例中，所述注册保活消息还携带所述第三级设备的层级信息、以及注册保活在所述第三级设备上设备的层级信息。

具体的，以第二级设备为例，第二级设备30秒保活定时器到时，需要向第一级设备发送保活消息，同时向第一级设备描述状态更新的下级设备信息。在DeviceList每一个子设备的描述中，增加Status标签表示该下级设备的最新状态，ON为在线，OFF为离线。DeviceDepth标签表示该子设备的层级信息，每上升一级，由上级设备对该层级加1再上报给上上级设备，这个值用于寻找最优路径。

具体消息格式如下：

MESSAGE sip:1级设备ID@1级设备目的域名或IP地址端口SIP/2.0Via:SIP/2.0/UDP源域名或IP地址端口

From:<sip:2级设备ID@源域名>；tag＝e8ba7be

To:<sip:1级设备ID@源域名>

Call-ID:2bb77845a58778458ab7784512877845ff@192.169.13.98

Contact:<sip:2级设备ID@源IP地址端口>

CSeq:1MESSAGE

Max-Forwards:70

Content-Type:Application/MANSCDP+xml

Content-Length:消息实体的字节长度

<？Xml version＝”1.0”？>

<Notify>

<CmdType>KeepAlive</CmdType>>

<SN>2</SN>

<DeviceID>2级设备ID</DeviceID>

<DeviceList Num＝1>

<Item>

<DeviceID>3级设备</DeviceID>

<Status>ON/OFF</Status>

<DeviceDepth>1</DeviceDepth>

</Item>

</DeviceList>

</Notify>

本实施例1台第三级设备会向3台第二级设备注册，每一台第二级设备也会向3台第一级设备注册。这样可能存在第一级设备收到了2台第二级设备对该第三级设备的注册，此时第一级设备基于表1维护一个设备映射表，保存每一个上报的路径，如表2所示。

表2多路径设备映射表

在异常情况下，当设备A宕机，第一级设备在90秒没有收到设备A保活消息后进行离线处理，将设备A上报的第三级设备从表2所示的链表中删除，根据此时链表中是否还有其他第二级设备的上报来判断是否将第三级设备置为离线。如表2所示情形，则仍旧认为第三级设备在线。后续配置下发可走设备B链路。

中心服务器VM对设备下发配置以及信息查询时，将一级级进行消息转发，通过表2所示的路由信息，参考设备层级寻找最优路径进行转发，若响应超时，可更换路径并将用时最少的路径标记为最优路径。

同理，本实施例第二级设备根据第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息，建立设备映射表，在接收第一级设备转发的配置以及查询消息时，根据建立的设备映射表进行转发。

在优选的实施例，可将设备的IP地址通过注册保活报文上报，这样可让VM直接与IPC进行信令交互。

在优选的实施例中，设备在向上级的保活消息中仅描述下级状态变化的设备，对状态不变的下级设备不向上级汇报。上级在没有收到下级设备的状态变动的保活消息时，可认为该下级设备状态未变化。

本申请技术方案，与现有的VM/NVR中心服务器模式相比，支持IPC集群可在零配置或批量单项配置的条件下，无需中心服务器参与，自发形成自治系统，完成设备管理，并能自动完成负载均衡。自治系统实现分布式架构，整个系统压力可做到负载均衡，避免中心设备因性能不足引起的业务异常、设备损坏等故障。自治系统的网状结构，一台设备与多台设备存在相互关系，可保证在一台设备故障的环境下，下级设备可以及时感知并更新上级节点，不影响所有其他设备的正常工作，满足高效性、可靠性、容错性等特点。

在一个实施例中，本申请还提供了一种监控系统内设备管理装置，所述监控系统内设备管理装置，应用于第二级设备，包括：

下级管理模块，用于接收第三级设备的注册请求，建立与第三级设备的管辖关系，管辖所述第三级设备；接收第三级设备的保活信息，更新第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息；

上级注册保活模块，用于向第一级设备发送注册请求，建立与第一级设备的管辖关系，被所述第一级设备所管辖；向所述第一级设备发送保活信息，以便第一级设备更新本第二级设备的设备信息以及注册保活在本第二级设备上设备的设备信息。

关于一种监控系统内设备管理装置的具体限定可以参见上文中对于一种监控系统内设备管理方法的限定，在此不再赘述。上述一种监控系统内设备管理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

本装置的一个实施例，所述下级管理模块在接收第三级设备的注册请求，建立与第三级设备的管辖关系时，执行如下操作：

通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息；

通过第二组播地址和端口接收所管辖的第三级设备的注册保活消息。

所述上级注册保活模块在向第一级设备发送注册请求，建立与第一级设备的管辖关系时，执行如下操作：

通过第一组播地址和端口向第一级设备发送发现请求，并接收所述第一级设备的响应消息，回复应答消息，建立与所述第一级设备的管辖关系，向所述第一级设备进行注册保活。

本装置的另一个实施例，所述下级管理模块通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息，执行如下操作：

通过第二组播地址和端口接收第三级设备的发现请求；

判断自身是否还有负载能力来管辖所述第三级设备，如果有则向所述第三级设备发送响应消息。

本装置的另一个实施例，所述上级注册保活模块接收所述第一级设备的响应消息，回复应答消息，执行如下操作：

所述响应消息中携带所述第一级设备的负载能力信息；

在接收到所述第一级设备的响应消息后，根据所述第一级设备的负载能力，判断是否选择所述第一级设备来管辖，向所选择的第一级设备回复应答消息。

本装置的另一个实施例，所述设备信息包括：所述第三级设备的状态信息、以及注册保活在所述第三级设备上设备的状态信息；所述第三级设备的层级信息、以及注册保活在所述第三级设备上设备的层级信息；

所述监控系统内设备管理装置，还包括：

转发模块，用于根据第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息，建立设备映射表，在接收第一级设备转发的配置以及查询消息时，根据建立的设备映射表进行转发。

本实施例一种监控系统内设备管理装置，以第二级设备举例来说明，容易理解的而是，所述第一、第二、第三级设备主要是为了描述相互之间的关系，本实施例的装置对每个级别的设备都同样适用。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (8)

1.一种监控系统内设备管理方法，其特征在于，所述监控系统内设备管理方法，应用于每一台第二级设备，包括：

接收第三级设备的注册请求，建立与第三级设备的管辖关系，管辖所述第三级设备；

接收第三级设备的保活信息，更新第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息；

向第一级设备发送注册请求，建立与第一级设备的管辖关系，被所述第一级设备所管辖；

向所述第一级设备发送保活信息，以便第一级设备更新本第二级设备的设备信息以及注册保活在本第二级设备上设备的设备信息；

其中，所述设备信息包括：所述第三级设备的状态信息、以及注册保活在所述第三级设备上设备的状态信息；所述第三级设备的层级信息、以及注册保活在所述第三级设备上设备的层级信息；

所述监控系统内设备管理方法，还包括：

根据第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息，建立设备映射表，在接收第一级设备转发的配置以及查询消息时，根据建立的设备映射表寻找最优路径进行转发，若响应超时，更换路径并将用时最少的路径标记为最优路径。

2.根据权利要求1所述的监控系统内设备管理方法，其特征在于，所述接收第三级设备的注册请求，建立与第三级设备的管辖关系；向第一级设备发送注册请求，建立与第一级设备的管辖关系，包括：

通过第一组播地址和端口向第一级设备发送发现请求，并接收所述第一级设备的响应消息，回复应答消息，建立与所述第一级设备的管辖关系，向所述第一级设备进行注册保活；

通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息；

通过第二组播地址和端口接收所管辖的第三级设备的注册保活消息。

3.根据权利要求2所述的监控系统内设备管理方法，其特征在于，所述通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息，包括：

通过第二组播地址和端口接收第三级设备的发现请求；

判断自身是否还有负载能力来管辖所述第三级设备，如果有则向所述第三级设备发送响应消息。

4.根据权利要求2所述的监控系统内设备管理方法，其特征在于，所述接收所述第一级设备的响应消息，回复应答消息，包括：

所述响应消息中携带所述第一级设备的负载能力信息；

在接收到所述第一级设备的响应消息后，根据所述第一级设备的负载能力，判断是否选择所述第一级设备来管辖，向所选择的第一级设备回复应答消息。

5.一种监控系统内设备管理装置，其特征在于，所述监控系统内设备管理装置，应用于每一台第二级设备，包括：

下级管理模块，用于接收第三级设备的注册请求，建立与第三级设备的管辖关系，管辖所述第三级设备；接收第三级设备的保活信息，更新第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息；

上级注册保活模块，用于向第一级设备发送注册请求，建立与第一级设备的管辖关系，被所述第一级设备所管辖；向所述第一级设备发送保活信息，以便第一级设备更新本第二级设备的设备信息以及注册保活在本第二级设备上设备的设备信息；

其中，所述设备信息包括：所述第三级设备的状态信息、以及注册保活在所述第三级设备上设备的状态信息；所述第三级设备的层级信息、以及注册保活在所述第三级设备上设备的层级信息；

所述监控系统内设备管理装置，还包括：

转发模块，用于根据第三级设备的设备信息以及注册保活在所述第三级设备上设备的设备信息，建立设备映射表，在接收第一级设备转发的配置以及查询消息时，根据建立的设备映射表寻找最优路径进行转发，若响应超时，更换路径并将用时最少的路径标记为最优路径。

6.根据权利要求5所述的监控系统内设备管理装置，其特征在于，所述下级管理模块在接收第三级设备的注册请求，建立与第三级设备的管辖关系时，执行如下操作：

通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息；

通过第二组播地址和端口接收所管辖的第三级设备的注册保活消息；

所述上级注册保活模块在向第一级设备发送注册请求，建立与第一级设备的管辖关系时，执行如下操作：

通过第一组播地址和端口向第一级设备发送发现请求，并接收所述第一级设备的响应消息，回复应答消息，建立与所述第一级设备的管辖关系，向所述第一级设备进行注册保活。

7.根据权利要求6所述的监控系统内设备管理装置，其特征在于，所述下级管理模块通过第二组播地址和端口接收第三级设备的发现请求，进行响应，向所述第三级设备发送响应消息，执行如下操作：

通过第二组播地址和端口接收第三级设备的发现请求；

判断自身是否还有负载能力来管辖所述第三级设备，如果有则向所述第三级设备发送响应消息。

8.根据权利要求6所述的监控系统内设备管理装置，其特征在于，所述上级注册保活模块接收所述第一级设备的响应消息，回复应答消息，执行如下操作：

所述响应消息中携带所述第一级设备的负载能力信息；

在接收到所述第一级设备的响应消息后，根据所述第一级设备的负载能力，判断是否选择所述第一级设备来管辖，向所选择的第一级设备回复应答消息。

Images