CN105939212A - 状态探测的方法及装置 - Google Patents

状态探测的方法及装置 Download PDF

Info

Publication number
CN105939212A
CN105939212A CN201610104971.XA CN201610104971A CN105939212A CN 105939212 A CN105939212 A CN 105939212A CN 201610104971 A CN201610104971 A CN 201610104971A CN 105939212 A CN105939212 A CN 105939212A
Authority
CN
China
Prior art keywords
pdp
detected equipment
response
response message
detection
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610104971.XA
Other languages
English (en)
Other versions
CN105939212B (zh
Inventor
黄晓朦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou DPTech Technologies Co Ltd
Original Assignee
Hangzhou DPTech Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou DPTech Technologies Co Ltd filed Critical Hangzhou DPTech Technologies Co Ltd
Priority to CN201610104971.XA priority Critical patent/CN105939212B/zh
Publication of CN105939212A publication Critical patent/CN105939212A/zh
Application granted granted Critical
Publication of CN105939212B publication Critical patent/CN105939212B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route

Abstract

本申请提供一种状态探测的方法及装置,所述方法包括:向被探测设备上的指定进程发送PDP探测保活协议探测报文;接收所述被探测设备返回的PDP应答报文;根据接收到的所述PDP应答报文针对所述指定进程进行状态探测。在本申请中,由于可以探测目标设备上的指定进程是否存活,因此,可以解决现有技术的问题。

Description

状态探测的方法及装置
技术领域
本申请涉及通信技术领域,尤其涉及一种状态探测的方法及装置。
背景技术
为了保护关键应用,网络中会设计一定的冗余备份链路,当网络发生故障时,网络设备可以快速检测出故障并将流量切换至备份链路以加快网络的收敛速度。
现有技术可以检测目标设备是否运行正常,但是无法检测出目标设备上的指定进程是否运行正常。因此,当网络发生故障时,现有技术只能将故障定位到目标设备,却无法将故障准确定位到目标设备上的具体进程。
发明内容
有鉴于此,本申请提供一种状态探测的方法及装置,来解决现有技术无法探测目标设备上指定进程是否存活的问题。
具体地,本申请是通过如下技术方案实现的:
根据本申请实施例的第一方面,提供一种状态探测的方法,所述方法应用于探测服务器上,所述方法包括:
向被探测设备上的指定进程发送PDP探测保活协议探测报文;
接收所述被探测设备返回的PDP应答报文;
根据接收到的所述PDP应答报文针对所述指定进程进行状态探测。
根据本申请实施例的第二方面,提供一种状态探测的装置,所述装置应用于探测服务器上,所述装置包括:
发送单元,用于向被探测设备上的指定进程发送PDP探测保活协议探测报文;
接收单元,用于接收所述被探测设备返回的PDP应答报文;
探测单元,用于根据接收到的所述PDP应答报文针对所述指定进程进行状态探测。
本申请提供状态探测的方法及装置,探测服务器可以向被探测设备上的指定进程发送PDP探测报文,并根据接收到的所述被探测设备上的指定进程根据所述PDP探测报文生成的PDP应答报文来判断所述被探测设备上的指定进程是否存活。在本申请中,由于可以探测目标设备上的指定进程是否存活,因此,可以解决现有技术的问题。
附图说明
图1是应用本申请实施例实现状态探测的一个应用场景示意图;
图2是本申请状态探测的方法的一个实施例流程图;
图3是本申请状态探测的装置所在设备的一种硬件结构图;
图4是本申请状态探测的装置的一个实施例框图;
图5是本申请状态探测的装置的另一个实施例框图;
图6是本申请状态探测的装置的另一个实施例框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
参见图1,为应用本申请实施例实现状态探测的方法的一个应用场景示意图。其中,探测设备可以称为DS(Detector Server,探测服务器),被探测设备可以称为DC(Detector Client,探测客户端)。DS可以为保活探测的发起方,在DS上可以启动保活探测服务,用于向DC持续发送自定义的PDP(Port DetectProtocol,探测保活协议)探测报文。在DC上可以运行探测应答服务,用于响应DS发送的PDP探测报文。
现有技术中,探测服务器DS可以持续向目标设备DC上发送保活报文,目标设备接收到保活报文后,返回应答报文。探测服务器根据是否收到应答报文和收到应答报文的时间与发送保活报文的时间间隔来判断目标设备是否存活。因为现有技术只能获取目标设备的整机状态,无法获取目标设备上的指定进程的存活状态,所以当需要获取目标设备上指定进程的运行状态时,现有技术无法满足需求。
本申请提供状态探测的方法及装置,探测服务器可以向被探测设备上的指定进程发送PDP探测报文,并根据接收到的所述被探测设备上的指定进程根据所述PDP探测报文生成的PDP应答报文来判断所述被探测设备上的指定进程是否存活。在本申请中,由于可以探测目标设备上的指定进程是否存活,因此,可以解决现有技术的问题。
参见图2,为本申请状态探测的方法的一个实施例流程图,该实施例应用在探测服务器DS上,包括了以下步骤:
步骤201:向被探测设备上的指定进程发送PDP探测报文。
上述PDP为本例中示出的一种自定义的探测保活协议。上述PDP探测报文为PDP协议中定义的一种用于对被探测设备上指定进程进行状态探测的报文。
在本例中,探测设备DS可以启动探测保活进程基于预设的发送周期向被探测设备DC上的指定进程周期性的发送PDP探测报文,该发送周期可以基于实际的需求进行设定,例如,发送周期可以设为10毫秒~3秒。
上述指定进程可以基于与该进程对应的指定端口来区分,DS在向上述指定进程发送PDP探测报文时,可以通过向DC上与该指定进程对应的指定端口发送PDP探测报文来实现。
其中,上述PDP探测报文可以选择UDP(User Datagram Protocol,用户数据报协议)作为承载协议,也可选择TCP(Transmission Control Protocol,传输控制协议)作为承载协议。当然,DS和DC所采用的承载协议必须统一。
在示出的一种实施方式中,PDP报文的封装格式可以如下表1所示:
表1
请参见表1,表1中各字段的含义可以如下所示:
Type字段可以表示当前报文的类型。对于PDP报文,该字段的取值可以被定义为固定值;例如,该字段的取值可以被定义为固定值0xf000,此固定值可以表示当前报文为PDP报文;
Length字段可以表示当前PDP报文的长度,长度范围可以为0~65535;
Version字段可以为固定值,此固定值可以为0x00000001;
Diag字段可以表示诊断字段。该诊断字段的长度为8个字节,用于携带DS对当前DC的探测结果,从而当该PDP报文被发送至DC时,可以协助DC基于该报文中携带的诊断结果了解DS的行为和状态探测结果,从而对自身协议栈的处理进行诊断。DC应答DS发送的PDP探测报文时,可以将Diag字段清零处理;
Action字段可以表示当前报文的动作,当Action的取值为0x01时,可以表示当前报文为DS发送至DC的PDP探测报文;当Action的取值为0x02时,可以表示当前报文为DC发送至DS的PDP应答报文;
Reserved字段可以为保留字段;
DS_seq字段可以表示DS的探测序列号,针对DC上的每一个进程,DS可以确保与其对应的DS_seq是唯一且单调递增的,递增的步长可以为1。
DC_seq字段可以表示应答序列号,当DC构建PDP应答报文时,可以将当前的seq填入DC_seq中。需要说明的是,DC在实现DC_seq时需针对每一个DS维护一个seq,DS会在收到DC_seq以后在后续的PDP报文中抄回此seq,供DC验证DS状态使用。
DS_second字段可以表示DS当前的时间秒数,需要说明的是,DS当前的时间秒数可以以1970-01-0100:00:00UTC(Coordinated Universal Time,协调世界时),即以1970年1月1日0时0分0秒UTC为基准来记录;
DC_second字段可以表示DC当前的时间秒数,可以与DS_second一样以1970年1月1日0时0分0秒UTC为基准来记录;
DS_microsecond字段可以表示DS当前的时间毫秒数,具体地,可以从DS中获取当前时间对应的纳秒数,并将该纳秒数转换为毫秒数;
DC_microsecond字段可以表示DC当前的时间毫秒数,具体地,可以从DC中获取当前时间对应的纳秒数,并将该纳秒数转换为毫秒数;
步骤202:接收所述被探测设备返回的PDP应答报文。
DC上运行的探测应答进程接收到来自DS的PDP探测报文后,可以解析并处理该PDP探测报文,并根据表1所示的PDP报文结构,构建PDP应答报文,然后将该PDP应答报文发送至DS。
需要说明的是,DC在构建PDP应答报文时,可以将接收到的PDP探测报文中的一些字段写入PDP应答报文中;例如,可以对接收到的PDP探测报文中DS_seq、DS_second以及DS_microsecond字段的内容进行复制,写入PDP应答报文。
步骤203:根据接收到的所述PDP应答报文针对所述指定进程进行状态探测。
DS接收到DC发送的PDP应答报文后,可以根据所述PDP应答报文针对DC上的指定进程进行状态探测。
其中,DS在根据PDP应答报文针对DC上的指定进程进行状态探测时,可以判断DC是否正常应答,来确定DC是否应答异常。
当DC应答异常时,DS可以将DC切换为down状态,该down状态可以表示DS认为DC上的指定进程没有存活。
当DC应答正常时,DS可以判断是否持续N秒接收到DC发送的PDP应答报文,其中,在实现时,N可以为大于30的自然数。当DS可以持续N秒接收到来自DC的PDP应答报文时,此时DS可以将DC由down状态切换为up状态,该up状态可以表示DS认为DC上的指定进程存活;当然,当DS未能连续N秒接收到来自DC的PDP应答报文时,DS可以确定DC为down状态。
在示出的一个示例中,DS在确定DC是否应答异常时,可以根据DC发送PDP应答报文的应答延时来实现。
DC发送的PDP应答报文可以携带DC的应答时间戳,其中该应答时间戳即为上述表1中的DS_second和DS_microsecond。
DS接收到DC发送的PDP应答报文后,可以根据PDP报文的应答时间戳来计算DC的应答延时。
在本实施例中,DS接收到DC发送的PDP应答报文后,可以从该应答报文中获取应答时间戳。获取到该应答时间戳后,DS可以根据该应答时间戳与本地时间戳计算出DC的应答延时。
在一个假设的示例中,DS发送至DC的PDP探测报文中的DS_second和DS_microsecond分别为1990年3月3日3时3分3秒和13毫秒。DC在基于该PDP探测报文构建PDP应答报文时,可以将该PDP探测报文中的DS_second和DS_microsecond的值对应填入至PDP应答报文中。
当DS接收到DC发送的PDP应答报文时,可以从该PDP应答报文中获取DS_second和DS_microsecond的取值。然后,DS可以获取本地时间戳,假设DS获取到的本地时间戳为1990年3月3日3时3分4秒13毫秒,此时DS可以计算获取到的DS_second和DS_microsecond字段的取值和本地时间戳的差值得到DC的应答延时为1秒。
计算出DC的应答延时后,DS可以根据该应答延时判断PDP应答报文的应答延时是否超过默认探测间隔或者自定义的设定值。当该应答延时超过默认探测间隔或者自定义的设定值时,可以确定DC应答异常;当该应答延时未超过默认探测间隔或者自定义的设定值时,可以确定DC应答正常。
当DC应答正常时,DS可以基于PDP应答报文来探测DC的状态。状态探测完成后,DS可以将探测结果发送至DC,以使DC根据该探测结果对自身协议栈的处理进行诊断。需要说明的是,该探测结果可以记录在DS发送至DC的PDP报文的Diag字段中。
当DC应答异常时,DS可以确定DC的状态为down,并将此确定结果记录在PDP报文的Diag字段中发送至DC。
在本例中,DS向DC发出的PDP探测报文中还可以携带将DS针对DC上指定进程的探测结果,从而使得DC可以根据该探测结果对该指定进程进行响应诊断。
其中,上述探测结果可以携带在如表1所示出的报文格式中的Diag字段中。
请参见下表2,表2为示出的一种Diag字段具体取值,以及对应诊断信息的列表:
表2
表2中的最后一列可以表示DS认为当前DC的状态。由表2可知,当Diag值不同时,可以表示DS对DC有如下探测结果:
当Diag值为0x00时,可以表示DS和DC间保活正常;
当Diag值为0x01时,可以表示探测无应答,即DS接收不到来自DC的应答报文;
当Diag值为0x02时,可以表示DS接收到的PDP应答报文的报文长度不正确。由表1可知,PDP应答报文的报文长度可以为0~65535,当PDP应答报文的报文长度不在此长度范围时,可以确定接收到的PDP应答报文的格式不正确;
当Diag值为0x03时,可以表示DS接收到的PDP应答报文的报文版本号不正确。由表1可知,PDP应答报文的报文版本号可以为0xf000,当PDP应答报文的报文版本号不为0xf000,可以确定接收到的PDP应答报文的格式不正确;
当Diag值为0x04时,可以表示DS接收到的PDP应答报文的Diag值不在能够解释的范围内,由表1可知,Diag值可以为8个字节,即取值范围可以为0~255,当PDP应答报文的Diag值不在此取值范围内时,可以确定接收到的PDP应答报文的格式不正确;
当Diag值为0x05时,可以表示DS接收到的PDP应答报文的Action值不在能够解释的范围内,由表1可知,Action的取值可以为0x01和0x02,当Action的取值不为0x01或0x02时,可以确定接收到的PDP应答报文的格式不正确;
当Diag值为0x06时,可以表示DS接收到的PDP应答报文的DS_seq值与DS本地记录的DS_seq值的绝对差值超过允许的范围,可以表示DC丢包严重;
当Diag值为0x07时,可以表示DS接收到的PDP应答报文的DC_seq值与DS本地记录的DC_seq值的绝对差值超过允许的范围,可以表示DC丢包严重;
当Diag值为0x08时,可以表示DS接收到的PDP应答报文的DS_seq值与DS本地记录的DS_seq值的绝对差值在允许的范围内;
当Diag值为0x09时,可以表示DS接收到的PDP应答报文的DC_seq值与DS本地记录的DC_seq值的绝对差值在允许的范围内;
当Diag值为0x0a时,可以表示DS对接收到的PDP应答报文的探测还未结束,也一直未发现异常。
可见,通过这种方式,当DC收到DS发出的PDP状态列表时,可以读取Diag字段中记录的信息,来对自身协议栈的处理进行诊断。
在本申请中,探测服务器可以向被探测设备上的指定进程发送PDP探测报文,并根据接收到的所述被探测设备上的指定进程根据所述PDP探测报文生成的PDP应答报文来判断所述被探测设备上的指定进程是否存活。在本申请中,由于可以探测目标设备上的指定进程是否存活,因此,可以解决现有技术的问题。
下面通过具体实施例对以上实施例进行详细说明:
探测设备DS通过向被探测设备DC上指定的端口发送PDP探测报文来探测DC上指定进程的状态。DS可以基于预设的发送周期发送该PDP探测报文,该发送周期可以基于实际的需求来进行设定,例如设为10毫秒~3秒。PDP报文的封装格式可见上表1。
在本实施例中,由表1可知,DS在构建PDP探测报文时,可以将当前的时间戳填入报文中的DS_second字段和DS_microsecond字段中。在一个假设的示例中,DS的当前时间戳可以为1990年3月3日3时3分3秒13毫秒,此时,该PDP探测报文中的DS_second字段和DS_microsecond字段的对应值可以分别为1990年3月3日3时3分3秒和13毫秒。
DS向DC发送了PDP探测报文后,可以接收到DC基于该PDP探测报文返回的PDP应答报文。
在本实施例中,DC在构建与该PDP探测报文对应的PDP应答报文时,可以将该PDP探测报文中的一些字段对应填入PDP应答报文中,这些字段可以包括DS_seq、DS_second以及DS_microsecond。
在一个假设的示例中,该PDP探测报文的DS_second字段和DS_microsecond字段的对应取值可以分别为1990年3月3日3时3分3秒和13毫秒。此时,DC可以通过将DS_second字段和DS_microsecond字段的取值对应填入PDP应答报文中,来完成对PDP应答报文的构建。
PDP应答报文构建完成后,DC可以将该PDP应答报文发送至DS。DS接收到该PDP应答报文后,可以根据所述PDP应答报文针对DC上的指定进程进行状态探测。
其中,DS在根据PDP应答报文针对DC上的指定进程进行状态探测时,可以判断DC是否正常应答,来确定DC是否应答异常。
在示出的一个示例中,DS在确定DC是否应答异常时,可以根据DC发出PDP应答报文的应答延时来实现。其中,应答延时可以通过PDP应答报文的应答时间戳和DS的本地时间戳计算得出。
在一个假设的示例中,DS可以从接收到的PDP应答报文中获取其应答时间戳DS_second和DS_microsecond。可以假设该应答时间戳DS_second和DS_microsecond分别为1990年3月3日3时3分3秒和13毫秒。然后,DS可以获取本地时间戳,可以假设该本地时间戳为1990年3月3日3时3分13秒17毫秒。此时,DS可以根据该应答时间戳和本地时间戳计算出DC的应答延时为10秒4毫秒。
在本实施例中,计算出DC的应答延时后,DS可以根据该应答延时判断PDP应答报文的应答延时是否超过默认探测间隔或者自定义的设定值。当该应答延时超过默认探测间隔或者自定义的设定值时,可以确定DC应答异常;当该应答延时未超过默认探测间隔或者自定义的设定值时,可以确定DC应答正常。
在一个假设的示例中,该默认探测间隔或自定义的设定值可以为10秒,当PDP应答报文的应答时间戳为1990年3月3日3时3分3秒13毫秒时,如果DS的本地时间戳为1990年3月3日3时3分13秒17毫秒,则可以由DC的应答延时为10秒4毫秒可知,DC应答异常;如果DS的本地时间戳为1990年3月3日3时3分8秒17毫秒,则可以由DC的应答延时为5秒4毫秒可知,DC应答正常。
当DC应答异常时,DS可以确定DC的状态为down,即DS认为此时DC没有存活。
当DC应答正常时,DS可以判断是否连续N秒接收到DC发送的PDP应答报文,其中,在实现时,N可以为大于30的自然数。当DS可以连续N秒接收到来自DC的PDP应答报文时,DS可以将DC由down状态切换为up状态,该up状态可以表示DS认为DC上的指定进程存活;当DS未能连续N秒接收到来自DC的PDP应答报文时,DS可以确定DC为down状态。
当DC应答正常时,DS可以根据该PDP应答报文针对DC上的指定进程进行状态探测。状态探测完成后,DS可以将探测结果发送至DC,以使DC根据该探测结果对自身协议栈的处理进行诊断,需要说明的是,该探测结果可以记录在DS发送至DC的PDP报文的Diag字段中。
当DC应答异常时,DS可以在确定DC的状态为down之后,将此确定结果记录在PDP报文的Diag字段中发送至DC。
在本例中,DS向DC发出的PDP探测报文中还可以携带将DS针对DC上指定进程的探测结果,从而使得DC可以根据该探测结果对该指定进程进行响应诊断。
其中,上述探测结果可以携带在如表1所示出的报文格式中的Diag字段中。
在本申请中,探测服务器可以向被探测设备上的指定进程发送PDP探测报文,并根据接收到的所述被探测设备上的指定进程根据所述PDP探测报文生成的PDP应答报文来判断所述被探测设备上的指定进程是否存活。在本申请中,由于可以探测目标设备上的指定进程是否存活,因此,可以解决现有技术的问题。
与前述状态探测的方法的实施例相对应,本申请还提供了状态探测的装置的实施例。
本申请状态探测的装置的实施例可以应用在探测服务器上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图3所示,为本申请状态探测的装置所在设备的一种硬件结构图,除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外,实施例中装置所在的设备通常还可以包括其他硬件,如负责处理报文的转发芯片等等。
请参考图4,为本申请状态探测的装置的一个实施例框图:
该装置可以包括:发送单元410、接收单元420以及探测单元430。
发送单元410,用于向被探测设备上的指定进程发送PDP探测保活协议探测报文;
接收单元420,用于接收所述被探测设备返回的PDP应答报文;
探测单元430,用于根据接收到的所述PDP应答报文针对所述指定进程进行状态探测。
在一个可选的实现方式中,所述发送单元410可以具体用于:
基于预设的发送周期向所述指定进程周期性的发送PDP探测报文。
在一个可选的实现方式中,所述探测单元430可以包括(如图5所示):
判断子单元430A,用于判断所述被探测设备是否应答异常;
切换子单元430B,用于当被探测设备应答异常时,将被探测设备切换为down状态。
在一个可选的实现方式中,所述判断子单元430A可以进一步用于:
当所述被探测设备应答正常时,判断是否持续N秒接收到所述被探测设备发出的PDP应答报文;
如果探测设备持续N秒接收到所述被探测设备发出的PDP应答报文,将被探测设备切换为up状态;
如果未能持续N秒接收到所述被探测设备发出的PDP应答报文,确定被探测设备为down状态。
在一个可选的实现方式中,所述PDP应答报文携带被探测设备的应答时间戳;
所述判断子单元430A可以具体用于:
根据所述应答时间戳以及本地时间戳计算被探测设备的应答时间;
根据计算出的应答时间判断PDP应答报文的应答延时是否超过默认探测间隔或者设定值;
如果所述应答延时超过默认探测间隔或者设定值,确定被探测设备应答异常;
如果所述应答延时未超过默认探测间隔或者设定值,确定被探测设备应答正常。
在一个可选的实现方式中,所述装置还可以包括(如图6所示):
诊断单元440,用于将携带针对所述指定进程的探测结果的PDP探测报文发送至被探测设备,以使所述被探测设备根据所述探测结果对所述指定进程进行响应诊断。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
在本申请中,探测服务器可以向被探测设备上的指定进程发送PDP探测报文,并根据接收到的所述被探测设备上的指定进程根据所述PDP探测报文生成的PDP应答报文来判断所述被探测设备上的指定进程是否存活。在本申请中,由于可以探测目标设备上的指定进程是否存活,因此,可以解决现有技术的问题。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

Claims (12)

1.一种状态探测的方法,其特征在于,所述方法应用于探测服务器上,所述方法包括:
向被探测设备上的指定进程发送PDP探测保活协议探测报文;
接收所述被探测设备返回的PDP应答报文;
根据接收到的所述PDP应答报文针对所述指定进程进行状态探测。
2.根据权利要求1所述的方法,其特征在于,所述向被探测设备上的指定进程发送PDP探测报文,包括:
基于预设的发送周期向所述指定进程周期性的发送PDP探测报文。
3.根据权利要求1所述的方法,其特征在于,所述根据接收到的所述PDP应答报文针对所述指定进程进行状态探测包括:
判断所述被探测设备是否应答异常;
当被探测设备应答异常时,将被探测设备切换为down状态。
4.根据权利要求3所述的方法,其特征在于,当所述被探测设备应答正常时,判断是否持续N秒接收到所述被探测设备发出的PDP应答报文;
如果探测设备持续N秒接收到所述被探测设备发出的PDP应答报文,将被探测设备切换为up状态;
如果未能持续N秒接收到所述被探测设备发出的PDP应答报文,确定被探测设备为down状态。
5.根据权利要求3所述的方法,其特征在于,所述PDP应答报文携带被探测设备的应答时间戳;
所述判断所述被探测设备是否应答异常包括:
根据所述应答时间戳以及本地时间戳计算被探测设备的应答时间;
根据计算出的应答时间判断PDP应答报文的应答延时是否超过默认探测间隔或者设定值;
如果所述应答延时超过默认探测间隔或者设定值,确定被探测设备应答异常;
如果所述应答延时未超过默认探测间隔或者设定值,确定被探测设备应答正常。
6.根据权利要求1所述的方法,其特征在于,所述方法还包括:
将携带针对所述指定进程的探测结果的PDP探测报文发送至被探测设备,以使所述被探测设备根据所述探测结果对所述指定进程进行响应诊断。
7.一种状态探测的装置,其特征在于,所述装置应用于探测服务器上,所述装置包括:
发送单元,用于向被探测设备上的指定进程发送PDP探测保活协议探测报文;
接收单元,用于接收所述被探测设备返回的PDP应答报文;
探测单元,用于根据接收到的所述PDP应答报文针对所述指定进程进行状态探测。
8.根据权利要求7所述的装置,其特征在于,所述发送单元具体用于:
基于预设的发送周期向所述指定进程周期性的发送PDP探测报文。
9.根据权利要求7所述的装置,其特征在于,所述探测单元包括:
判断子单元,用于判断所述被探测设备是否应答异常;
切换子单元,用于当被探测设备应答异常时,将被探测设备切换为down状态。
10.根据权利要求9所述的装置,其特征在于,所述判断子单元进一步用于:
当所述被探测设备应答正常时,判断是否持续N秒接收到所述被探测设备发出的PDP应答报文;
如果探测设备持续N秒接收到所述被探测设备发出的PDP应答报文,将被探测设备切换为up状态;
如果未能持续N秒接收到所述被探测设备发出的PDP应答报文,确定被探测设备为down状态。
11.根据权利要求9所述的装置,其特征在于,所述PDP应答报文携带被探测设备的应答时间戳;
所述判断子单元具体用于:
根据所述应答时间戳以及本地时间戳计算被探测设备的应答时间;
根据计算出的应答时间判断PDP应答报文的应答延时是否超过默认探测间隔或者设定值;
如果所述应答延时超过默认探测间隔或者设定值,确定被探测设备应答异常;
如果所述应答延时未超过默认探测间隔或者设定值,确定被探测设备应答正常。
12.根据权利要求7所述的装置,其特征在于,所述装置还包括:
诊断单元,用于将携带针对所述指定进程的探测结果的PDP探测报文发送至被探测设备,以使所述被探测设备根据所述探测结果对所述指定进程进行响应诊断。
CN201610104971.XA 2016-02-25 2016-02-25 状态探测的方法及装置 Active CN105939212B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610104971.XA CN105939212B (zh) 2016-02-25 2016-02-25 状态探测的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610104971.XA CN105939212B (zh) 2016-02-25 2016-02-25 状态探测的方法及装置

Publications (2)

Publication Number Publication Date
CN105939212A true CN105939212A (zh) 2016-09-14
CN105939212B CN105939212B (zh) 2019-05-07

Family

ID=57153153

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610104971.XA Active CN105939212B (zh) 2016-02-25 2016-02-25 状态探测的方法及装置

Country Status (1)

Country Link
CN (1) CN105939212B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107465621A (zh) * 2017-08-18 2017-12-12 迈普通信技术股份有限公司 一种路由器发现方法、sdn控制器、路由器和网络系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090161560A1 (en) * 2006-08-30 2009-06-25 Huawei Technologies Co., Ltd. Node, method and system of fault localization in multicast mpls networks
CN102177681A (zh) * 2011-04-21 2011-09-07 华为技术有限公司 检测故障的方法和系统
CN103369403A (zh) * 2013-08-05 2013-10-23 江苏省广电有线信息网络股份有限公司南京分公司 机顶盒点播包分析系统和分析方法
CN103383689A (zh) * 2012-05-03 2013-11-06 阿里巴巴集团控股有限公司 一种服务进程故障检测方法、装置及服务节点
CN104065526A (zh) * 2013-03-22 2014-09-24 腾讯科技(深圳)有限公司 一种服务器故障报警的方法和装置
CN104515244A (zh) * 2013-09-26 2015-04-15 珠海格力电器股份有限公司 空调遥控器和空调遥控系统及方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090161560A1 (en) * 2006-08-30 2009-06-25 Huawei Technologies Co., Ltd. Node, method and system of fault localization in multicast mpls networks
CN102177681A (zh) * 2011-04-21 2011-09-07 华为技术有限公司 检测故障的方法和系统
CN103383689A (zh) * 2012-05-03 2013-11-06 阿里巴巴集团控股有限公司 一种服务进程故障检测方法、装置及服务节点
CN104065526A (zh) * 2013-03-22 2014-09-24 腾讯科技(深圳)有限公司 一种服务器故障报警的方法和装置
CN103369403A (zh) * 2013-08-05 2013-10-23 江苏省广电有线信息网络股份有限公司南京分公司 机顶盒点播包分析系统和分析方法
CN104515244A (zh) * 2013-09-26 2015-04-15 珠海格力电器股份有限公司 空调遥控器和空调遥控系统及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107465621A (zh) * 2017-08-18 2017-12-12 迈普通信技术股份有限公司 一种路由器发现方法、sdn控制器、路由器和网络系统
CN107465621B (zh) * 2017-08-18 2020-08-11 迈普通信技术股份有限公司 一种路由器发现方法、sdn控制器、路由器和网络系统

Also Published As

Publication number Publication date
CN105939212B (zh) 2019-05-07

Similar Documents

Publication Publication Date Title
CN101404599B (zh) 网络故障检测的方法、主设备、从设备、控制终端和系统
CN104202201B (zh) 一种日志处理方法、装置及终端
KR101443071B1 (ko) 웹페이지의 에러 체크 시스템
CN106027326A (zh) 链路健康探测方法及装置
US20170351560A1 (en) Software failure impact and selection system
CN104065526A (zh) 一种服务器故障报警的方法和装置
CN107251456B (zh) 用于对控制网络中的装置进行时间同步的方法
CN102571438B (zh) 远程监护系统及其自动网络诊断方法
US8036132B1 (en) Systems, devices, and methods for determining network failures
CN105849702A (zh) 集群系统,服务器设备,集群系统管理方法和计算机可读记录介质
CN104202199A (zh) 检测接口状态并据接口状态处理接口故障的方法及系统
CN107404456A (zh) 错误定位方法及装置
CN101800672B (zh) 设备检测方法和设备
CN106919489B (zh) 应用程序的应用界面异常退出的监测方法及装置
CN105939212A (zh) 状态探测的方法及装置
CN108989130A (zh) 一种网络故障上报方法及装置
CN105959128A (zh) 故障处理方法、装置以及网络设备
CN105959129B (zh) 监测网络故障的方法及装置
TWI644228B (zh) 伺服器及其監控方法
CN105939220A (zh) 远程端口镜像的实现方法及装置
CN103401779B (zh) 报文转发路径切换方法、装置及网络设备
CN106341342A (zh) 维持通信连接的方法、装置、终端及服务器
CN115276844A (zh) 通信模组的测试方法、装置及电子设备
CN106230878B (zh) 一种基于AllJoyn框架的设备服务调用方法及装置
CN105939401B (zh) 处理报文的方法及装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Address after: Binjiang District and Hangzhou city in Zhejiang Province Road 310051 No. 68 in the 6 storey building

Applicant after: Hangzhou Dipu Polytron Technologies Inc

Address before: Binjiang District and Hangzhou city in Zhejiang Province Road 310051 No. 68 in the 6 storey building

Applicant before: Hangzhou Dipu Technology Co., Ltd.

CB02 Change of applicant information
GR01 Patent grant
GR01 Patent grant