DHCP延时事件处理方法及装置.pdf

本发明提供一种DHCP延时事件处理方法及装置，应用于网络设备或者主机上，包括：在发生用户DHCP延时事件时，根据该事件的触发延时时长确定该事件所归属的管理链表，并将该事件作为管理链表的尾节点添加到管理链表中，其中同一个管理链表中每个延时事件的延时触发时长相同；在管理链表对应的定时器超时时，处理该定时器对应的头节点的DHCP延时事件，并删除该头节点；在管理链表的头节点发生变化时，确定定时器对应的管理链表中延时触发时间点最早的头节点，更新管理链表对应的定时器，使该定时器的超时时间点更新为该头节点的延时触发时间点。本发明能够有效提升DHCP延时事件的处理速度，从而提升DHCP对IP地址的管理效率。

权利要求书1.  一种DHCP延时事件处理装置，应用于网络设备或者主机上，其特征 在于，该装置包括： 节点管理单元，用于在产生用户DHCP延时事件时，根据该事件的触发 延时时长确定该事件所归属的管理链表，并将该事件作为归属的管理链表的 尾节点添加到该管理链表中，其中同一个管理链表中每个延时事件的延时触 发时长相同； 事件处理单元，用于在管理链表对应的定时器超时时，处理该定时器对 应的头节点的DHCP延时事件，并删除该头节点； 定时更新单元，用于在管理链表的头节点发生变化时，确定定时器对应 的管理链表中延时触发时间点最早的头节点，更新管理链表对应的定时器， 使该定时器的超时时间点更新为该头节点的延时触发时间点。 2.  如权利要求1所述的装置，其特征在于：其中每个管理链表唯一对应 一个定时器；或者多个管理链表对应同一个定时器。 3.  如权利要求1所述的装置，其特征在于：所述节点管理单元进一步用 于在确定没有该DHCP延时事件所归属的管理链表时，为该事件创建对应的 归属管理链表；所述事件处理单元进一步用于在删除头节点之后进一步检查 该头节点所属管理链表是否还有其他节点，如果没有则删除该管理链表。 4.  如权利要求1所述的装置，其特征在于：所述DHCP延时事件为DHCP 续约延时事件或DHCP租约释放延时事件。 5.  如权利要求1所述的装置，所述事件处理单元进一步用于在DHCP 延时事件提前终止时，确定管理链表中与该DHCP延时事件对应的节点，并 删除该节点。 6.  一种DHCP延时事件处理方法，应用于网络设备或者主机上，其特征 在于，该方法包括以下步骤： 步骤A，在发生用户DHCP延时事件时，根据该事件的触发延时时长确 定该事件所归属的管理链表，并将该事件作为管理链表的尾节点添加到管理 链表中，其中同一个管理链表中每个延时事件的延时触发时长相同； 步骤B，在管理链表对应的定时器超时时，处理该定时器对应的头节点 的DHCP延时事件，并删除该头节点； 步骤C，在管理链表的头节点发生变化时，确定定时器对应的管理链表 中延时触发时间点最早的头节点，更新管理链表对应的定时器，使该定时器 的超时时间点更新为该头节点的延时触发时间点。 7.  如权利要求6所述的方法，其特征在于：其中每个管理链表唯一对应 一个定时器；或者多个管理链表对应同一个定时器。 8.  如权利要求6所述的方法，其特征在于： 所述步骤A进一步包括：在确定没有该DHCP延时事件所归属的管理链 表时，创建对应的管理链表； 所述步骤B进一步包括：在删除头节点之后进一步检查该头节点所属管 理链表是否还有其他节点，如果没有则删除该管理链表。 9.  如权利要求6所述的方法，其特征在于：所述DHCP延时事件为DHCP 续约延时事件或DHCP租约释放延时事件。 10.  如权利要求6所述的方法，其特征在于，所述步骤B进一步包括： 在DHCP延时事件提前终止时，确定管理链表中与该DHCP延时事件对应的 节点，并删除该节点。

说明书DHCP延时事件处理方法及装置
技术领域
本发明涉及网络通信技术领域，尤其涉及一种DHCP延时事件处理方法 及装置。
背景技术
一台计算机或其他终端要想接入IP网络，必须有一个唯一的IP（Internet  Protocol，因特网协议）地址，此IP地址可通过DHCP（Dynamic Host Configuration  Protocol，动态主机配置协议）自动获取。DHCP分为客户端和服务器端，每一 台动态获取IP地址的计算机上都有一个DHCP客户端，用来与DHCP服务器端 交互。
DHCP服务器为用户分配一个IP地址，同时为用户指定一个租约时间。用 户需要在租约到期前，根据DHCP协议中的续约算法请求续约，续约成功则继 续使用此IP地址，不成功则释放此IP地址，以便DHCP服务器将此IP地址分 配给其他用户。
无论DHCP客户端还是DHCP服务器端都需要使用定时器来维护租约时间， 用于判断IP地址是否到期。
对DHCP客户端而言，普通计算机中的DHCP客户端只需请求并记录一个 IP地址，然后由定时器控制，根据DHCP协议提供的算法进行续约。而对于网 络边缘设备，其内置的DHCP客户端需要请求并记录成千上万用户的IP地址并 为其续约。
对DHCP服务器端而言，网络管理员会划分不同的地址池，并配置不同的 租约时间，这样在服务器中就要维护具有不同租约时间的IP地址，其IP地址数 量可能达到万级甚至几十万级。
当有大量的IP地址需要维护时，现有技术通常通过维护单链表的方式实现。 这种单链表方式随着IP地址数量的增加，其处理效率会明显下降。
对于DHCP客户端而言，每一个节点包括IP地址的获取时间及租约时间， 然后根据DHCP续约算法计算出需要续约的时间，最后按照续约时间的先后顺 序建立链表。同时，启动定时器，每隔一段时间遍历时间链表，删除时间链表 中已经超时的节点，然后续约，根据剩余的租约时间计算续约超时时间，再重 新挂到链表上。
对于DHCP服务器端而言，每分配一个IP地址，就计算出其租约到期的时 间，然后按照租约到期时间的先后顺序建立链表。同时，启动定时器，每隔一 段时间遍历时间链表，删除已经超时的IP地址，以便重新分配给其他设备。
综上所述，可以看出所有节点都挂在一条链表上，此单链表随着IP地址数 量的增加，逐步加长。然而，无论是插入节点还是删除节点都需要遍历链表， 随着链表的增长，遍历耗时增加，系统资源消耗较大，必然导致效率降低。
发明内容
有鉴于此，本发明提供一种DHCP延时事件处理装置，应用于网络设备 或者主机上，其特征在于，该装置包括：
节点管理单元，用于在发生用户DHCP延时事件时，根据该事件的触发延时 时长确定该事件所归属的管理链表，并将该事件作为管理链表的尾节点添加到管 理链表中，其中同一个管理链表中每个延时事件的延时触发时长相同；
事件处理单元，用于在管理链表对应的定时器超时时，处理该定时器对 应的头节点的DHCP延时事件，并删除该头节点；
定时更新单元，用于在管理链表的头节点发生变化时，确定定时器对应 的管理链表中延时触发时间点最早的头节点，更新管理链表对应的定时器， 使该定时器的超时时间点更新为该头节点的延时触发时间点。
本发明还提供一种DHCP延时事件处理方法，应用于网络设备或者主机 上，其特征在于，该方法包括以下步骤：
步骤A，在发生用户DHCP延时事件时，根据该事件的触发延时时长确 定该事件所归属的管理链表，并将该事件作为管理链表的尾节点添加到管理 链表中，其中同一个管理链表中每个延时事件的延时触发时长相同；
步骤B，在管理链表对应的定时器超时时，处理该定时器对应的头节点 的DHCP延时事件，并删除该头节点；
步骤C，在管理链表的头节点发生变化时，确定定时器对应的管理链表 中延时触发时间点最早的头节点，更新管理链表对应的定时器，使该定时器 的超时时间点更新为该头节点的延时触发时间点。
本发明能够有效提升了网络设备或主机对于DHCP延时事件的管理效 率，有效节约了网络设备或主机在管理DHCP延时事件上所消耗的系统资源， 避免了现有技术中长时间的遍历处理。
附图说明
图1是本发明一种实施方式中DHCP延时事件处理装置的逻辑结构及其 基础硬件环境的示意图。
图2是本发明一种实施方式中DHCP延时事件处理方法的流程图。
图3是本发明一种实施方式中DHCP延时事件链表管理的流程图。
图4是本发明一种实施方式中定时器超时处理的流程图。
图5是本发明一种实施方式中提前终止延时事件处理的流程图。
图6是本发明一种实施方式中单一定时器与链表对应关系的示意图。
图7是本发明一种实施方式中多个定时器与链表对应关系的示意图。
具体实施方式
以下结合附图对本发明进行详细描述。
在一种较佳的实施方式中，本发明提供一种基于软件实施方式实现的 DHCP延时事件处理装置，该装置应用在网络设备或者主机上，本发明并不 排除诸如硬件或者逻辑器件等其他实现方式。如图1所示，该网络设备或者 主机通常包括CPU、内存、非易失性存储器以及其他硬件。该DHCP延时事 件处理装置作为一个逻辑层面的虚拟装置，其通过CPU运行对应的计算机程 序实现，该装置包括节点管理单元、事件处理单元以及定时更新单元。请参 考图2，该装置的使用和运行过程包括以下步骤。
步骤101，在产生用户DHCP延时事件时，根据该事件的触发延时时长确 定该事件所归属的管理链表，并将该事件作为管理链表的尾节点添加到管理链 表中，其中同一个管理链表中每个延时事件的延时触发时长相同；
步骤102，在管理链表对应的定时器超时时，处理该定时器对应的头节点 的DHCP延时事件，并删除该头节点；
步骤103，在管理链表的头节点发生变化时，确定定时器对应的管理链表 中延时触发时间点最早的头节点，更新管理链表对应的定时器，使该定时器的 超时时间点更新为该头节点的延时触发时间点。
上述DHCP延时事件可以是典型的DHCP续约延时事件或DHCP租约释放延 时事件。在DHCP协议的C/S（Client/Server，客户端/服务器）模型中，DHCP客 户端负责为用户请求IP地址和管理IP地址的续约。当DHCP客户端向DHCP服 务器端请求IP地址时，DHCP服务器为用户分配IP地址，同时指定一个租约时间， 此租约时间为DHCP服务器允许该用户占用此IP地址的时间长度。若用户在租约 到期后，仍希望继续使用此IP地址，则需在租约到期前向DHCP服务器端请求续 约。续约成功则继续使用此IP地址，不成功则释放此IP地址，以便DHCP服务 器将此IP地址分配给其他用户。因此，DHCP续约延时是指DHCP客户端从获取 IP地址到下一次请求续约的时间长度。此续约延时是根据DHCP协议中的续约算 法进行计算的，默认为租约时间的一半。所述DHCP续约延时事件是指DHCP客 户端在到达续约延时时间点时请求续约的事件。DHCP租约释放延时是指DHCP 服务器端从分配IP地址到租约到期的时间长度，即租约时间。所述DHCP租约释 放延时事件是指DHCP服务器端在租约到期后释放IP地址的事件。
现以DHCP续约延时事件处理为例，在一种优选的方式中，DHCP客户端 内置于网络边缘设备，负责为多个用户申请IP地址和管理续约。在此优选方式 中，通过建立多个管理链表（以下简称为“链表”）管理用户的DHCP续约延时 事件，同一链表中每个续约延时事件的续约延时时长相同。优选地，采用一个 定时器处理DHCP续约延时事件。请参考图3，在产生用户DHCP续约延时事 件时，需根据该续约延时事件的延时时长将该续约延时事件作为节点添加到对 应的链表中。如图6所示，若节点9为新发生的续约延时事件，首先根据DHCP 协议的续约算法计算出该节点的续约延迟时间。例如，通过续约计算得出该续 约延时事件的续约延时时长为3天，则查询是否有对应的链表。如图6所示， 链表3的延时时长为3天，并且此链表中已有节点7和节点8，因此，将节点9 添加到节点8的后面，作为当前链表3的尾节点。如图6所示，若节点10为新 发生的续约延时事件，该延时事件的续约延时时长为4天，查询时发现无此延 时时长对应的链表，则新建链表4，此链表的延时时长为4天，将节点10作为 链表4的头节点添加入链表。综上所述可以看出，所有节点都进行了分类管理， 每一个节点的添加无需遍历已存在的所有节点，只需查询到对应链表，将节点 添加到对应链表尾部，此操作即可实现同一链表内节点按照时间先后顺序排列， 进而保证每一个链表的头节点是相应链表中最早超时触发的节点。
在上述实施例中，采用一个定时器实现对多个链表的管理，将定时器对应 链表中最早触发的节点的续约延时时间点作为定时器的超时时间点。由于每个 链表的头节点都是相应链表中最早触发的节点，因此，定时器的超时时间点一 定是所有链表头节点中最早超时触发的头节点的续约延时时间点。当定时器对 应链表的头节点发生变化时，需更新定时器，将最早超时触发的节点的续约延 时时间点作为定时器的超时时间点。如图6所示，节点10为新发生的续约延时 事件，此延时事件的延时时长为4天，这个事件的延时时长是之前不存在的， 因此需新建链表4，并将节点10作为头节点（也是尾节点）添加到链表4中。 此时，系统需更新定时器，重新比较各链表中头节点的触发延时时间点，即比 较各个链表中的头节点--节点1、节点4、节点7及节点10的触发延时时间点， 确定最早触发的头节点，将该头节点的延时时间点作为定时器的超时时间点， 也就是重新设定定时器的超时时长。
请参考图4，在定时器超时时，需处理定时器对应头节点的续约延时事 件，并删除该头节点，若该头节点所属链表无其他节点，则删除该链表。此 时需要重新执行上一段确定最早触发的头节点的处理，因此定时器对应的头 节点将发生变化，所以需相应更新定时器的超时时间点。如图6所示，假设 当前定时器对应的头节点为链表1的头节点1，当定时器超时时，处理节点1 的续约延时事件，即DHCP客户端向DHCP服务器端请求续约，要求继续使 用此IP地址，同时删除节点1。此时，节点2将作为链表1的头节点，由于 头节点发生变化，需重新比较每一个链表的头节点，即节点2、节点4、节点 7及节点10，确定最早延时触发头节点，若节点10确定为最早延时触发节点， 则将节点10的续约延时时间点作为定时器超时时间点。当定时器下一次超时 处理时，处理节点10的续约延时事件，同时删除节点10。由于节点10是 链表4的唯一节点，因此，删除节点10后，需将链表4删除。以此类推，头 节点发生变化，继续更新定时器。
进一步来说，在处理续约延时事件时，又分为两种情况：续约成功和续 约不成功。续约成功时，重新计算续约延时时间，添加到相应链表的尾部， 相当于产生了一个新的DHCP延时事件。但是如果在一定时间内续约不成功 时，且剩余租约时间＞1分钟，则重新计算续约延时时间，续约成功则添加 到相应链表尾部，等待下一次续约，若始终无法续约成功，而导致剩余租约 时间≤1分钟，用户需释放此IP地址，重新向DHCP服务器请求新的IP地址。
在DHCP延时事件处理过程中，还存在一种提前终止延时事件的情况， 例如，用户主动释放IP地址，请参考图5。若发生提前终止延时事件，则删 除延时事件对应的节点，若该节点所属链表无其他节点，则删除该链表，若 该节点为定时器对应的头节点，则需更新定时器。如图6所示，节点1为定 时器对应节点，若节点1在租约到期前主动释放IP地址，则删除节点1，比较 节点2、节点4、节点7及节点10，确定最早触发节点的延时时间更新定时器。 若主动释放IP地址的节点不是定时器对应的头节点，如节点2到节点10，删除 节点后无需更新定时器。对于节点10，由于该节点是链表4的唯一节点，因此 在删除节点10时，同时删除链表4。
在另一种优选的方式中，以DHCP租约释放延时事件为例。DHCP租约 释放延时事件发生于DHCP服务器端，在本实施例中，优选地，采用多个定 时器处理DHCP租约释放延时事件。在DHCP服务器端，管理员划分不同的 地址池，同一个地址池中IP地址的租约时间相同。DHCP服务器每分配一个 IP地址会创建一个节点，将该节点添加到具有相同租约时间的链表的尾部， 这样可以保证同一链表中节点按照顺序超时。如图7所示，每一个链表对应 一个定时器。图中延时时长在本实施例中等同于租约时间。定时器的超时时 间设置为对应链表头节点的租约释放延时时间。定时器超时时，删除对应链 表的头节点，同时处理该节点的租约释放延时事件，即收回此IP地址。由于 服务器管理的延时事件数量级通常较高，因此通常更适宜采用一个定时器唯 一对应一个链表的方式。这种方式与前述一个定时器对应多个链表的方式不 同之处在于：在前述实施方式中，一旦某个链表的头节点发生变化，那么需 要重新考察定时器指向哪个链表的头节点；而在本实施方式中，由于定时器 是一个链表独占的，因此每个定时间只需要固定指向本链表中当前的头节点 即可，无需考察所有链表中的头节点进行比较；每次更新定时器时，仅需要 按照独占该定时器链表的当前头节点的延时触发时间点来进行更新即可。
在上述实施例中，无论是采用单一定时器还是多个定时器管理DHCP延 时链表，其本质都是建立分类链表，以便准确高效处理DHCP延时事件。上 述两种实施方式均可应用于DHCP客户端或DHCP服务器端。根据需要处理 的IP地址数量确定采用何种方式。采用本发明的实现，可以有效避免现有技 术中对于延时事件管理效率低下而导致系统资源消耗严重的问题，避免了现 有技术中长时间的遍历处理。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本 发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在 本发明保护的范围之内。