CN107294848B - 一种路由器请求消息的发送方法及装置 - Google Patents
一种路由器请求消息的发送方法及装置 Download PDFInfo
- Publication number
- CN107294848B CN107294848B CN201610229148.1A CN201610229148A CN107294848B CN 107294848 B CN107294848 B CN 107294848B CN 201610229148 A CN201610229148 A CN 201610229148A CN 107294848 B CN107294848 B CN 107294848B
- Authority
- CN
- China
- Prior art keywords
- router
- message
- host
- request message
- sent
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/26—Route discovery packet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例提供了一种路由器请求消息的发送方法及装置,涉及通信技术领域,其中所述发送方法包括:向路由器发送路由器请求消息;在发送路由器请求消息后的预设时间值内,若未收到路由器发送的路由器通告消息,则重新发送路由器请求消息,直到主机接收到路由器通告消息;其中,相邻两次发送路由器请求消息后的预设时间值不同。本发明实施例提供的技术方案能够在发生丢包事件时,持续重发路由器请求消息,直到主机接收到路由器通告消息,同时控制相邻两次路由器请求消息发送的时间间隔,避免大量主机同时发送路由器请求消息而增加网络负载。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种路由器请求消息的发送方法及装置。
背景技术
邻居发现协议是IPv6协议(Internet Protocol Version 6,互联网协议版本六)的一个基本的组成部分,它实现了在IPv4中的地址解析协议(ARP)、控制报文协议(ICMP)中的路由器发现部分、重定向协议的所有功能,并具有邻居不可达检测机制。但是,在邻居发现协议中并没有针对路由器请求消息的丢包情况提供相应的处理方法,因此在某些网络应用场景中,协议存在相应的先天缺陷。比如一个连接在以太网上被桥接的家用网关,当WAN(Wide Area Network,广域网)口还没被激活时,在重发初始路由器请求消息后,主机就会放弃发送消息。
根据邻居发现协议规定,当一个主机的接口被***初始化时,为了快速的获取到路由器通告(Router Advertisement)消息,主机会至多发送3次路由器请求(RouterSolicitation)消息,且每次发送的时间至少相隔4秒。一旦初始的路由器请求消息被全部丢弃,主机就不能进行网络连接。假设被发送的相邻两个路由器通告消息的时间间隔最大为1800秒,那么如果因为路由器请求消息的丢包原因,导致主机在这30分钟之内都没有任何网络链接。这种延迟可能在任何场景中都不能被接收。
针对上述路由器请求消息丢包的描述,主机需要持续重发路由器请求消息直到主机收到路由器通告消息为止,或者直到主机愿意接受没有路由器存在为止。但是当网络中存的主机数量较大的时候,如果大量主机同时重发路由器请求消息,也可能会产生大量的网络流量,从而增量网络的负载。
发明内容
本发明实施例提供了一种路由器请求消息的发送方法及装置,以解决现有技术中因丢包事件而造成的长时间网络延迟以及因大量主机重新发送路由器请求消息而增加的网络负载。
为了解决上述技术问题,本发明采用如下技术方案:
依据本发明实施例的一个方面提供了一种路由器请求消息的发送方法,所述发送方法包括:
向路由器发送路由器请求消息;
在发送路由器请求消息后的预设时间值内,若未收到路由器发送的路由器通告消息,则重新发送路由器请求消息,直到主机接收到路由器通告消息;其中,相邻两次发送路由器请求消息后的预设时间值不同。
进一步地,
其中,n表示主机发送路由器请求消息的次数,第一随机性因子和第二随机性因子均为分布在[-a,a]区间内的随机数,且0<a<1;前一预设时间值为主机相邻两次发送路由器请求消息后的两个预设时间值中,较早时间发送路由器请求消息后的预设时间值。
进一步地,当所述预设时间值大于预设的最大重发时间间隔时,
预设时间值=(1+第三随机性因子)×预设的最大重发时间间隔值;
其中,第三随机性因子为分布在[-a,a]区间内的随机数。
进一步地,所述向路由器发送路由器请求消息的步骤之后,所述发送方法还包括:
若主机发送路由器请求消息的次数等于最大发送计数或者主机发送路由器请求消息的持续时间等于最大发送时间时,停止向路由器发送路由器请求消息。
进一步地,所述向路由器发送路由器请求消息的步骤之后,所述发送方法还包括:
接收路由器在预设时间值内未接收到主机发送的路由器请求消息而发送的丢包告警信息。
进一步地,所述丢包告警信息携带在路由器向主机发送的互联网控制信息协议版本六ICMPv6报文中的预留字段中。
依据本发明实施例的另一个方面提供了一种路由器请求消息的发送装置,所述发送装置包括:
发送模块,用于向路由器发送路由器请求消息;
重发模块,用于在发送路由器请求消息后的预设时间值内,当未收到路由器发送的路由器通告消息时,重新发送路由器请求消息,直到主机接收到路由器通告消息;其中,相邻两次发送路由器请求消息后的预设时间值不同。
进一步地,
其中,n表示主机发送路由器请求消息的次数,第一随机性因子和第二随机性因子均为分布在[-a,a]区间内的随机数,且0<a<1;前一预设时间值为主机相邻两次发送路由器请求消息后的两个预设时间值中,较早时间发送路由器请求消息后的预设时间值。
进一步地,当所述预设时间值大于预设的最大重发时间间隔时,
预设时间值=(1+第三随机性因子)×预设的最大重发时间间隔值;
其中,第三随机性因子为分布在[-a,a]区间内的随机数。
进一步地,所述发送装置还包括:
停发消息模块,用于当主机发送路由器请求消息的次数等于最大发送计数或者主机发送路由器请求消息的持续时间等于最大发送时间时,停止向路由器发送路由器请求消息。
进一步地,所述发送装置还包括:
接收模块,用于接收路由器在预设时间值内未接收到主机发送的路由器请求消息而发送的丢包告警信息。
进一步地,所述丢包告警信息携带在路由器向主机发送的互联网控制信息协议版本六ICMPv6报文中的预留字段中。
本发明的有益效果是:
上述方案,主机可持续重发路由器请求消息,直到主机接收到路由器通告消息为止,避免了因发生丢包事件而造成的长时间网络延迟,同时控制相邻两次路由器请求消息发送的时间间隔,避免大量主机同时发送路由器请求消息而增加网络负载。
附图说明
图1表示本发明第一实施例提供的路由器请求消息的发送方法;
图2表示本发明提供的ICMPv6报文的结构示意图;
图3表示本发明提供的ICMPv6报文的另一结构示意图;
图4表示本发明第二实施例提供的路由器请求消息的发送装置框图。
具体实施方式
下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例,然而应当理解,可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本发明,并且能够将本发明的范围完整的传达给本领域的技术人员。
第一实施例
本发明实施例提供了一种路由器请求消息的发送方法,如图1所示,该发送方法包括:
步骤S101、向路由器发送路由器请求消息。
其中,这里的所述的“向路由器发送路由器请求消息”,不仅指主机第一次向路由器发送路由器请求消息,还包括主机因在发送路由器请求消息后的一定时间内未接收到路由器发送的路由器通告消息而重新向路由器发送的路由器请求消息。
步骤S102、在发送路由器请求消息后的预设时间值内,若未收到路由器发送的路由器通告消息,则重新发送路由器请求消息,直到主机接收到路由器通告消息。
为使主机在发生丢包事件时,仍旧能够及时接收到路由器发送的路由器通告消息,完成网络连接,减小网络时延,在本发明实施例中,规定主机在发送路由器请求消息后的一定时间(即预设时间值)内,若未收到路由器发送的路由器通告消息,则重新发送路由器通告消息,直到主机接收到路由通告消息位置。
需要说明的是,对于路由器发送的路由器通告消息,一种情况是:路由器根据主机发送的路由器请求消息作出响应而发出的路由器通告消息;另一种情况是:路由器周期性地向主机发送的路由器通告消息,以通告它的存在以及配置的链路和网络参数。路由器通告消息包含在连接(on-link)确定、地址配置的前缀和跳数限制值中等。
其中,为了避免网络中大量主机同时发送路由器请求消息而产生大量的网络流量,从而增加网络负载,本发明实施例中,控制路由器请求消息发送的时间间隔,使相邻两次发送路由器请求消息后的预设时间值不同。这样可降低出现大量主机同时发送路由器请求消息的概率,减小网络负载。
进一步地,本发明实施例中,提供了一种优选的计算预设时间值的方法,如下述计算公式所示:
其中,n表示主机发送路由器请求消息的次数,n取整数。前一预设时间值为主机相邻两次发送路由器请求消息后的两个预设时间值中,较早时间发送路由器请求消息后的预设时间值。第一随机性因子和第二随机性因子均为分布在[-a,a]区间内的随机数,且0<a<1,也就是在每一次计算预设时间值时,第一随机性因子和第二随机性因子都是在[-a,a]区间随机选择的数值,这样大大降低了发送路由器请求消息的时间间隔出现相同情况的概率,也大大降低了出现大量主机同时发送路由器请求消息的概率,从而减小网络负载。在本发明实施例中,区间[-a,a]优选为[-1,1]。
进一步地,对于上述预设时间值的计算方法,从计算公式可看出预设时间值随路由器请求消息发送次数的增加而增大,当预设时间值过于大时,会导致主机长时间没有网络连接,造成长时间的网络延迟,严重影响用户的使用体验,因此,本发明实施例中,规定当根据上述计算公式计算得到的预设时间值大于预设的最大重发时间间隔时,按照下述计算公式计算预设时间值:
预设时间值=(1+第三随机性因子)×预设的最大重发时间间隔值;
其中,第三随机性因子也为分布在[-a,a]区间内的随机数。预设的最大重发时间间隔值用来规定预设时间值的取值上限,该最大重发时间间隔的取值可根据实际需要设定,本发明实施例对此不进行限定。
进一步地,为进一步避免大量主机同时发送路由器请求消息,本发明实施例中规定:当主机发送路由器请求消息的次数等于最大发送计数或者主机发送路由器请求消息的持续时间等于最大发送时间时,停止向路由器发送路由器请求消息。此时,可认为主机完成一周期的路由器请求消息的发送,当然在主机没有接收到路由器通告消息时,主机会继续进入下一循环周期,即主机继续向路由器发送路由器请求消息的发送,直到接收到路由器通告消息,完成网络连接。
进一步地,为进一步完善本发明实施例提供的路由器请求消息的发送方法,本发明实施例还增加了对丢包的告警事件。当路由器在一定时间(即预设时间值)内未收到主机发送的路由器请求消息,则向主机发送丢包告警信息,而当主机接收到路由器发送的告警信息时,可通告给用户,使用户实时的了解自己的邻居发现过程中的问题,并及时采用相应的措施进行处理或者规避相关问题。其中,这里所述的“预设时间值”与主机发送路由器请求消息后的预设时间值为同一时间,也就是当主机发送路由器请求消息后的预设时间值内未收到路由器通告消息,同时路由器也会在预设时间值内因未收到主机发送的路由器请求消息而向主机发送丢包告警信息。
其中,在本发明实施例中,丢包告警信息携带在路由器向主机发送的互联网控制信息协议版本六ICMPv6报文中的预留字段中。本发明实施例借助协议字段的可扩展性,通过ICMPv6报文可实现对丢包事件的实时告警。由于ICMPv6报文的报文体是可变的,因此当ICMPv6报文的类型和代码的组合确定后,在ICMPv6报文体的最后预留一个字节,用来构造路由器请求消息丢包的预警信息通告信息。
将预留字段的数据部分可进行如下定义:
预警字段由预警(Alert)标志位和预警类型(Alert type)两个字段所组成。
当用户收到异常报告模块的异常通告信息后,通过解析ICMPv6选项字段中所记录的异常状态字段的值,可以动态的获取当前路由器请求消息是否存在丢包情况。
为进一步理解本发明实施例提供的路由器请求消息的发送方法,下面以一具体实施例加以说明:
主机第一次发送路由器请求消息给路由器时,主机与路由器之间开始消息交换。当主机成功收到适当的响应或多个响应(来自一个路由器或多个路由器)时,消息交换终结。如果主机在规定的时间内未能收到来自路由器的路由器通告消息,则主机必须重新发送路由器请求消息。下面对具体实现过程进行描述:
(1)变量定义
为实现该具体实施例提供的方法,***需要维护下列几个变量,以此用来控制和描述主机对路由器请求消息的重发行为:
RTT:重发超时(Retransmission Timeout),即相邻两次路由器请求消息发送的时间间隔。
RDF:随机性因子(Randomization Factor),对应上述中的第一随机性因子、第二随机性因子以及第三随机性因子。
IRTT:初始重发时间(Initial Retransmission Time),对应上述计算公式中的预设初始重发时间间隔值,是重发时间的一个初始化数值,一般可将其设置为4秒。
MRTT:最大重发时间(Maximum Retransmission Time),对应上述计算公式中的预设的最大重发时间间隔值,用来规定RTT的取值上限,一般可将其设置为3600秒。
MRTC:最大重发计数(Maximum Retransmission Count),对应上述中的最大发送计数。
MRTD:最大重发持续时间(Maximum Retransmission Duration),对应上述中的最大发送时间。
(2)算法实现
随着每个路由器请求消息的发送或重新发送,主机将按照下列规则计算RTT。如果在消息交换终结前RTT已经到期,且主机未收到路由器通告消息,则主机需要重新计算RTT并重发路由器请求消息。
在此方法中,为了尽量减小大量主机同步发送路由器请求消息,每个新的RTT计算都包括随机性因子(RDF),它是一个均匀分布在[-0.1,+0.1]区间(对应上述的[-a,a]区间,在该具体实施例中优选[-0.1,+0.1])的随机数。其中,选择随机数的算法应当根据每个主机的调用产生不同随机数序列。
其中,第一个路由器请求消息发送后的RTT基于IRTT,即:
RTT=IRTT+RDF×IRTT;
后续每个路由器请求消息发送后的RTT基于前一个RTT(以下称为RTTprev)的值:
RTT=2×RTTprev+RDF×RTTprev;
其中,上述计算公式中的“2”为一个经验值,当然还可根据实际需要设定其他数值。
MRTT用来规定RTT取值上限(忽略因使用RDF而增加的随机性),当MRTT=0,RTT的取值没有上限,当根据上述两个RTT的计算公式得到的RTT值大于MRTT时,RTT以下述计算公式得到数值的为准:
RTT=MRTT+RDF×MRTT;
MRTC用来规定主机可以发送路由器请求消息的次数上限。一旦主机已经发送MRTC次消息,则主机和路由器之间消息交换失败,主机停止向路由器发送路由器请求消息。但是,当MRTC取值为0时,路由器请求消息发送的次数没有上限。
MRTD用来规定主机发送路由器请求消息的时间长度上限。一旦从主机首次发送消息开始,经过MRTD时间后,则主机和路由器之间消息交换失败,主机停止向路由器发送路由器请求消息。但是,当MRTD取值为0时,路由器请求消息发送的持续时间没有上限。
其中,如果MRTC和MRTD的取值均不为0,则只要两个限制条件中的一个条件满足时,则主机和路由器之间的消息交换都会失败。
在此具体实施例中,为使主机能够持续重发路由器请求消息直到主机收到路由器通告消息为止,算法中将设定:MRTC=MRTD=0。
(3)丢包告警
本发明实施例借助协议字段的可扩展性,通过ICMPv6报文实现对丢包事件的实时告警。
首先介绍一下ICMPv6消息格式,如图2和图3所示。每一个ICMPv6报文在传送时都是附加在一个IPv6基本报头和若干(或没有)IPv6扩展报头之后。其中,下一个报头值58表示ICMPv6报文。
其中,根据预警字段的定义,可以按照实际需求对预留字段的长度进行相应调整,在此为描述方便,假设预警字段占用1个字节,其中预警标志占用3bit,预警类型占用5bit,如图3所示。
例如,当预警标志位=000时,表示ICMPv6消息无预警状况,则直接处理此报文;当预警标志位=001时,表示此报文存在预警,触发预警事件,同时读取后续的相应预警类型值,发出预警报告信息,并通告给用户。预警类型存放了路由器请求消息丢包的报文预警错误类型。如用00000表示路由器请求消息丢包等。
综上所述,上述方案,主机可持续重发路由器请求消息,直到主机接收到路由器通告消息为止,避免了因发生丢包事件而造成的长时间网络延迟,同时控制相邻两次路由器请求消息发送的时间间隔,避免大量主机同时发送路由器请求消息而增加网络负载。此外,本发明实施例还利用协议字段的可扩展性,通过ICMPv6的预留字段,对丢包事件进行告警,以使用户实时的了解自己的邻居发现过程中的问题,并及时采用相应的措施进行处理或者规避相关问题。
第二实施例
本发明实施例提供了一种路由器请求消息的发送装置,如图4所示,该发送装置包括:
发送模块401,用于向路由器发送路由器请求消息。
其中,这里的发送模块401向路由器发送路由器请求消息,不仅指主机第一次向路由器发送路由器请求消息,还包括主机因在发送路由器请求消息后的一定时间内未接收到路由器发送的路由器通告消息而重新向路由器发送的路由器请求消息。
重发模块402,用于在发送路由器请求消息后的预设时间值内,当未收到路由器根据路由器请求消息进行响应的路由器通告消息时,重新发送路由器请求消息,直到主机接收到路由器通告消息;其中,相邻两次发送路由器请求消息后的预设时间值不同。
为使主机在发生丢包事件时,仍旧能够及时接收到路由器发送的路由器通告消息,完成网络连接,减小网络时延,在本发明实施例中,重发模块402规定主机在发送路由器请求消息后的一定时间(即预设时间值)内,若未收到路由器发送的路由器通告消息,则重新发送路由器通告消息,直到主机接收到路由通告消息位置。
需要说明的是,对于路由器发送的路由器通告消息,一种情况是:路由器根据主机发送的路由器请求消息作出响应而发出的路由器通告消息;另一种情况是:路由器周期性地向主机发送的路由器通告消息,以通告它的存在以及配置的链路和网络参数。路由器通告消息包含在连接(on-link)确定、地址配置的前缀和跳数限制值中等。
其中,为了避免网络中大量主机同时发送路由器请求消息而产生大量的网络流量,从而增加网络负载,本发明实施例中,控制路由器请求消息发送的时间间隔,使相邻两次发送路由器请求消息后的预设时间值不同。这样可降低出现大量主机同时发送路由器请求消息的概率,减小网络负载。
进一步地,本发明实施例中,提供了一种优选的计算预设时间值的方法,如下述计算公式所示:
其中,n表示主机发送路由器请求消息的次数,n取整数。前一预设时间值值为主机相邻两次发送路由器请求消息后的两个预设时间值中,较早时间发送路由器请求消息后的预设时间值。第一随机性因子和第二随机性因子均为分布在[-a,a]区间内的随机数,且0<a<1,也就是在每一次计算预设时间值时,第一随机性因子和第二随机性因子都是在[-a,a]区间随机选择的数值,这样大大降低了发送路由器请求消息的时间间隔出现相同情况的概率,也大大降低了出现大量主机同时发送路由器请求消息的概率,从而减小网络负载。在本发明实施例中,区间[-a,a]优选为[-1,1]。
进一步地,对于上述预设时间值的计算方法,从计算公式可看出预设时间值随路由器请求消息发送次数的增加而增大,当预设时间值过于大时,会导致主机长时间没有网络连接,造成长时间的网络延迟,严重影响用户的使用体验,因此,本发明实施例中,规定当根据上述计算公式计算得到的预设时间值大于预设的最大重发时间间隔时,按照下述计算公式计算预设时间值:
预设时间值=(1+第三随机性因子)×预设的最大重发时间间隔值;
其中,第三随机性因子也为分布在[-a,a]区间内的随机数。预设的最大重发时间间隔值用来规定预设时间值的取值上限,该最大重发时间间隔的取值可根据实际需要设定,本发明实施例对此不进行限定。
进一步地,该发送装置还包括:
停发消息模块,用于当主机发送路由器请求消息的次数等于最大发送计数或者主机发送路由器请求消息的持续时间等于最大发送时间时,停止向路由器发送路由器请求消息。
为进一步避免大量主机同时发送路由器请求消息,本发明实施例中规定:当主机发送路由器请求消息的次数等于最大发送计数或者主机发送路由器请求消息的持续时间等于最大发送时间时,停止向路由器发送路由器请求消息。此时,可认为主机完成一周期的路由器请求消息的发送,当然在主机没有接收到路由器通告消息时,主机会继续进入下一循环周期,即主机继续向路由器发送路由器请求消息的发送,直到接收到路由器通告消息,完成网络连接。
进一步地,该发送装置还包括:
接收模块,用于接收路由器在预设时间值内没有接收到主机发送的路由器请求消息而发送的丢包告警信息。
为进一步完善本发明实施例提供的路由器请求消息的发送方法,发明实施例还增加了对丢包的告警事件。当路由器在一定时间(即预设时间值)内未收到主机发送的路由器请求消息,则向主机发送丢包告警信息,而当主机接收到路由器发送的告警信息时,可通告给用户,使用户实时的了解自己的邻居发现过程中的问题,并及时采用相应的措施进行处理或者规避相关问题。其中,这里所述的“预设时间值”与主机发送路由器请求消息后的预设时间值为同一时间,也就是当主机发送路由器请求消息后的预设时间值内未收到路由器通告消息,同时路由器也因在预设时间值内未收到主机发送的路由器请求消息而向主机发送丢包告警信息。
其中,在本发明实施例中,丢包告警信息携带在路由器向主机发送的互联网控制信息协议版本六ICMPv6报文中的预留字段中。本发明实施例借助协议字段的可扩展性,通过ICMPv6报文可实现对丢包事件的实时告警。由于ICMPv6报文的报文体是可变的,因此当ICMPv6报文的类型和代码的组合确定后,在ICMPv6报文体的最后预留一个字节,用来构造路由器请求消息丢包的预警信息通告信息。
将预留字段的数据部分可进行如下定义:
预警字段由预警(Alert)标志位和预警类型(Alert type)两个字段所组成。
当用户收到异常报告模块的异常通告信息后,通过解析ICMPv6选项字段中所记录的异常状态字段的值,可以动态的获取当前路由器请求消息是否存在丢包情况。
为进一步理解本发明实施例提供的路由器请求消息的发送方法,下面以一具体实施例加以说明:
主机第一次发送路由器请求消息给路由器,主机与路由器之间开始消息交换。当主机成功收到适当的响应或多个响应(来自一个路由器或多个路由器)时,消息交换终结。如果主机在规定的时间内未能收到来自路由器的路由器通告消息,则主机必须重新发送路由器请求消息。下面对具体实现过程进行描述:
(1)变量定义
为实现该具体实施例提供的方法,***需要维护下列几个变量,以此用来控制和描述主机对路由器请求消息的重发行为:
RTT:重发超时(Retransmission Timeout),即相邻两次路由器请求消息发送的时间间隔。
RDF:随机性因子(Randomization Factor),对应上述中的第一随机性因子、第二随机性因子以及第三随机性因子。
IRTT:初始重发时间(Initial Retransmission Time),对应上述计算公式中的预设初始重发时间间隔值,是重发时间的一个初始化数值,一般可将其设置为4秒。
MRTT:最大重发时间(Maximum Retransmission Time),对应上述计算公式中的预设的最大重发时间间隔值,用来规定RTT的取值上限,一般可将其设置为3600秒。
MRTC:最大重发计数(Maximum Retransmission Count),对应上述中的最大发送计数。
MRTD:最大重发持续时间(Maximum Retransmission Duration),对应上述中的最大发送时间。
(2)算法实现
随着每个路由器请求消息的发送或重新发送,主机将按照下列规则计算RTT。如果在消息交换终结前RTT已经到期,且主机未收到路由器通告消息,则主机需要重新计算RTT并重发路由器请求消息。
在此方法中,为了尽量减小大量主机同步发送路由器请求消息,每个新的RTT计算都包括随机性因子(RDF),它是一个均匀分布在[-0.1,+0.1]区间(对应上述的[-a,a]区间,在该具体实施例中优选[-0.1,+0.1])的随机数。其中,选择随机数的算法应当根据每个主机的调用产生不同随机数序列。
其中,第一个路由器请求消息发送后的RTT基于IRTT,即:
RTT=IRTT+RDF×IRTT;
后续每个路由器请求消息发送后的RTT基于前一个RTT(以下称为RTTprev)的值:
RTT=2×RTTprev+RDF×RTTprev;
其中,上述计算公式中的“2”为一个经验值,当然还可根据实际需要设定其他数值。
MRTT用来规定RTT取值上限(忽略因使用RDF而增加的随机性),当MRTT=0,RTT的取值没有上限,当根据上述两个RTT的计算公式得到的RTT值大于MRTT时,RTT以下述计算公式得到数值的为准:
RTT=MRTT+RDF×MRTT;
MRTC用来规定主机可以发送路由器请求消息的次数上限。一旦主机已经发送MRTC次消息,则主机和路由器之间消息交换失败,主机停止向路由器发送路由器请求消息。但是,当MRTC取值为0时,路由器请求消息发送的次数没有上限。
MRTD用来规定主机发送路由器请求消息的时间长度上限。一旦从主机首次发送消息开始,经过MRTD时间后,则主机和路由器之间消息交换失败,主机停止向路由器发送路由器请求消息。但是,当MRTD取值为0时,路由器请求消息发送的持续时间没有上限。
其中,如果MRTC和MRTD的取值均不为0,则只要两个限制条件中的一个条件满足时,则主机和路由器之间的消息交换都会失败。
在此具体实施例中,为使主机能够持续重发路由器请求消息直到主机收到路由器通告消息为止,算法中将设定:MRTC=MRTD=0。
(3)丢包告警
本发明实施例借助协议字段的可扩展性,通过ICMPv6报文实现对丢包事件的实时告警。
首先介绍一下ICMPv6消息格式,如图2所示。每一个ICMPv6报文在传送时都是附加在一个IPv6基本报头和若干(或没有)IPv6扩展报头之后。当下一个报头值58表示ICMPv6报文。
其中,根据预警字段的定义,可以按照实际需求对预留字段的长度进行相应调整,在此为描述方便,假设预警字段占用1个字节,其中预警标志占用3bit,预警类型占用5bit,如图3所示。
例如,当预警标志位=000时,表示ICMPv6消息无预警状况,则直接处理此报文;当预警标志位=001时,表示此报文存在预警,触发预警事件,同时读取后续的相应预警类型值,发出预警报告信息,并通告给用户。预警类型存放了路由器请求消息丢包的报文预警错误类型。如用00000表示路由器请求消息丢包等。
综上所述,上述方案,主机通过重发模块402可持续重发路由器请求消息,直到主机接收到路由器通告消息为止,避免了因发生丢包事件而造成的长时间网络延迟,同时控制相邻两次路由器请求消息发送的时间间隔,避免大量主机同时发送路由器请求消息而增加网络负载。此外,本发明实施例还利用协议字段的可扩展性,通过ICMPv6的预留字段,对丢包事件进行告警,以使用户实时的了解自己的邻居发现过程中的问题,并及时采用相应的措施进行处理或者规避相关问题。
以上所述的是本发明的优选实施方式,应当指出对于本技术领域的普通人员来说,在不脱离本发明所述的原理前提下还可以作出若干改进和润饰,这些改进和润饰也在本发明的保护范围内。
Claims (10)
2.根据权利要求1所述的发送方法,其特征在于,当所述预设时间值大于预设的最大重发时间间隔时,
预设时间值=(1+第三随机性因子)×预设的最大重发时间间隔值;
其中,第三随机性因子为分布在[-a,a]区间内的随机数。
3.根据权利要求1所述的发送方法,其特征在于,所述向路由器发送路由器请求消息的步骤之后,所述发送方法还包括:
若主机发送路由器请求消息的次数等于最大发送计数或者主机发送路由器请求消息的持续时间等于最大发送时间时,停止向路由器发送路由器请求消息。
4.根据权利要求1所述的发送方法,其特征在于,所述向路由器发送路由器请求消息的步骤之后,所述发送方法还包括:
接收路由器在预设时间值内未接收到主机发送的路由器请求消息而发送的丢包告警信息。
5.根据权利要求4所述的发送方法,其特征在于,所述丢包告警信息携带在路由器向主机发送的互联网控制信息协议版本六ICMPv6报文中的预留字段中。
7.根据权利要求6所述的发送装置,其特征在于,当所述预设时间值大于预设的最大重发时间间隔时,
预设时间值=(1+第三随机性因子)×预设的最大重发时间间隔值;
其中,第三随机性因子为分布在[-a,a]区间内的随机数。
8.根据权利要求6所述的发送装置,其特征在于,所述发送装置还包括:
停发消息模块,用于当主机发送路由器请求消息的次数等于最大发送计数或者主机发送路由器请求消息的持续时间等于最大发送时间时,停止向路由器发送路由器请求消息。
9.根据权利要求6所述的发送装置,其特征在于,所述发送装置还包括:
接收模块,用于接收路由器在预设时间值内未接收到主机发送的路由器请求消息而发送的丢包告警信息。
10.根据权利要求9所述的发送装置,其特征在于,所述丢包告警信息携带在路由器向主机发送的互联网控制信息协议版本六ICMPv6报文中的预留字段中。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610229148.1A CN107294848B (zh) | 2016-04-13 | 2016-04-13 | 一种路由器请求消息的发送方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610229148.1A CN107294848B (zh) | 2016-04-13 | 2016-04-13 | 一种路由器请求消息的发送方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107294848A CN107294848A (zh) | 2017-10-24 |
CN107294848B true CN107294848B (zh) | 2020-09-22 |
Family
ID=60095595
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610229148.1A Active CN107294848B (zh) | 2016-04-13 | 2016-04-13 | 一种路由器请求消息的发送方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107294848B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112492648B (zh) * | 2020-12-18 | 2021-07-02 | 深圳市微网力合信息技术有限公司 | 一种数据丢包处理方法、***及终端 |
CN112636877B (zh) * | 2020-12-18 | 2021-07-06 | 深圳市微网力合信息技术有限公司 | 一种基于wifi6的数据传输方法、***及终端 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1077559A1 (en) * | 1999-08-17 | 2001-02-21 | Telefonaktiebolaget Lm Ericsson | Method and device for determining a time-parameter |
JP4214793B2 (ja) * | 2003-02-19 | 2009-01-28 | 日本電気株式会社 | 無線通信システム、サーバ、基地局、移動端末及びそれらに用いる再送タイムアウト時間決定方法 |
CN1863033A (zh) * | 2005-05-14 | 2006-11-15 | 腾讯科技(深圳)有限公司 | 获取网络超时重传间隔的方法及网络中数据传输的方法 |
CN101009690A (zh) * | 2006-01-28 | 2007-08-01 | 华为技术有限公司 | 一种物理终端状态确认方法及装置 |
-
2016
- 2016-04-13 CN CN201610229148.1A patent/CN107294848B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN107294848A (zh) | 2017-10-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2652896B1 (en) | Repeater nodes in shared media networks | |
JP5317235B2 (ja) | 無線ローカル・エリア・ネットワークにおいてマルチキャスト・データの確認応答および再伝送を行う方法および装置 | |
Arkko et al. | Failure detection and locator pair exploration protocol for IPv6 multihoming | |
Speakman et al. | PGM reliable transport protocol specification | |
JP5637988B2 (ja) | 無線ローカル・エリア・ネットワークにおいてマルチキャスト・データの確認応答の要求および伝送を行う装置 | |
US20170149675A1 (en) | Packet retransmission method and apparatus | |
US7327683B2 (en) | Method and apparatus for disseminating topology information and for discovering new neighboring nodes | |
US7970828B2 (en) | Liveness monitoring in a publish/subscribe messaging system | |
US6845091B2 (en) | Mobile ad hoc extensions for the internet | |
US7061856B2 (en) | Data throughput over lossy communication links | |
US8411583B2 (en) | Method of performing polling procedure in a wireless communication system | |
JP2002158675A (ja) | 多重ノードネットワークにおいて各固有接続を最大データ率に適合するための方法及びプロトコル | |
DeSimone et al. | Wireless data: Systems, standards, services | |
JP2009525708A (ja) | プロトコルリンクレイヤ | |
EP2774322B1 (en) | Apparatus and method for transmitting a message to multiple receivers | |
Cheng et al. | Congestion control with dynamic threshold adaptation and cross‐layer response for TCP Vegas over IEEE 802.11 wireless networks | |
CN107294848B (zh) | 一种路由器请求消息的发送方法及装置 | |
Daldoul et al. | Block negative acknowledgement protocol for reliable multicast in IEEE 802.11 | |
CN111279644B (zh) | 用于更新无线网格网络中重传次数的方法和设备 | |
Rocha et al. | Performance evaluation of DTSN in wireless sensor networks | |
Chao et al. | Throughput improvements using the random leader technique for the reliable multicast wireless LANs | |
JP2009060238A (ja) | 送信方法、通信システムおよび通信装置 | |
CN110661597B (zh) | 利用基于公告机制的可靠数据传输协议的数据传输方法 | |
JP2004080259A (ja) | 通信端末装置およびパケット通信方法 | |
Cheng et al. | An adaptive bandwidth estimation mechanism for SCTP over wireless networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |