CN107040476A - 一种面向实时流计算的动态逐级反压方法 - Google Patents
一种面向实时流计算的动态逐级反压方法 Download PDFInfo
- Publication number
- CN107040476A CN107040476A CN201710140963.5A CN201710140963A CN107040476A CN 107040476 A CN107040476 A CN 107040476A CN 201710140963 A CN201710140963 A CN 201710140963A CN 107040476 A CN107040476 A CN 107040476A
- Authority
- CN
- China
- Prior art keywords
- pressure
- task
- node
- queue
- pressure signal
- 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
Links
Classifications
-
- 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/12—Avoiding congestion; Recovering from congestion
- H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/526—Mutual exclusion algorithms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
- H04L41/083—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for increasing network speed
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一种面向实时流计算的动态逐级反压方法,根据任务(Task)节点的当前自身负载情况来调整上游向其发送数据的速率,当某一Task过载导致延迟增加,上游的Bolt会减缓向下游发射的速率,更多的资源会被用来处理当前的正在处理的数据上,避免因阻塞、数据超时、重发等导致的延迟增加。当Task的负载降低至最小阈值且持续sensitivity秒,Task会向上游发送取消反压信号,上游Task收到取消反压信号后首先会检查自身是否处于反压状态,若是则会恢复上一次的发射速度,只有当组件恢复至初试速度时才会消除反压状态。本发明减少拓扑中单个任务对整体延迟的影响、反压过程平滑、系统不会出现负载振荡。
Description
技术领域
本发明涉及信息技术领域,具体涉及一种面向实时流计算的动态逐级反压方法。
背景技术
从社交网络资讯(以提供热门话题或实时搜索)到广告处理数据引擎,实时流计算在当今工业中被广泛地使用,如Apahe Storm,Twitter’s Heron,Apache Flink,SparkStreaming,Samza等。在这些系统中,数据的产生完全由数据源确定,数据源的动态变化及状态不统一导致数据流的速率呈现出了突发性的特征,而数据流的突发性特征常常导致过载的发生,发生过载还有以下几个原因:网络拥塞,资源利用率高,干扰,异质性,IO高频阻塞等。因此,在实时流计算中,过载是常见且难以避免的。
实时流计算已被许多知名企业应用于大数据计算领域,如淘宝实时分析、阿里云Galaxy实时计算、携程网站性能监控等。对于实时性系统,系统的响应性和稳定性是关注的重点。响应意味着降低处理数据的延迟,即数据计算延迟,例如,数据从它输入至系统中到其结果反映给用户所经过的时间;稳定性意味着系统能够稳定持久地在集群中运行。而过载的发生极易导致系统整体的数据计算延迟增加和不稳定甚至不可用。
对于流计算而言,数据流是不可控的:数据到达时机不可控、数据质量不可控、上游数据流量不可控。以阿里巴巴集团2016年11月11交易情况为例,当天成交额达178亿美元,阿里云于最高峰时每秒处理17.5万笔交易,支付宝于最高峰时每秒处理12万笔,这个交易额是平时的数十万倍,这就要求系统能够动态适应不确定的数据流,具有大数据流量动态匹配的能力。而现有的大部分实时流计算系统缺大数据流量动态匹配的能力,如ApacheStorm,Spark Streaming等。在实时流计算系统中,计算结构是一个有向无环图(DAG),称为拓扑(Topology),拓扑由数据流(Steam),数据流的生成者组件(Spout)和运算组件(Bolt)组成。Task是拓扑中Spout或Bolt在运行时的实例。拓扑中的数据通常由上游发送组件主动推送给下游接收组件,上游组件在推送数据时不会考虑下游组件的负载情况、工作状态等因素,如果下游组件因过载无法处理数据,实时流计算系统一般采用快速失败(fail-fast)策略——如果接收组件不能处理传入的数据,系统将其丢弃。如果系统没有实现数据的容错,那么这个fail-fast将会导致无限制的数据被丢弃,即使系统实现了数据的容错,也只是简单地将丢失的数据重新发送,没有动态匹配的能力。这样的设计会导致Topology在消耗所有集群资源的情况下拓扑任务没有任何进度。
Mitzenmacher M提出的方法是通过让输入的数据随机选择下游的两个最小负载的服务器节点来减少延迟。但是,这种技术本质上依赖输入的数据获取所有服务器节点的最新负载信息,而在快速移动的以毫秒为单位进行的流处理系统中,持续地监控服务器节点负载会严重加剧系统负荷,这使得这种方式难以真正实现。Twitter的Heron是2016年提出的实时流计算系统,实现的方法是直接遏制源头的反压策略,但这种方法可能不是最优的,因为可能仅仅只需要遏制上游的发送速度,而直接遏制源头的策略会导致整体Topology延迟取决于运行最慢的组件。
发明内容
为了克服现有的实时流计算方法的拓扑中单个任务影响整体延迟、反压过程不平滑、系统容易出现负载振荡的不足,本发明提出了一种减少拓扑中单个任务对整体延迟的影响、反压过程平滑、系统不会出现负载振荡的面向实时流计算的动态逐级反压方法,此方法根据任务(Task)节点的当前自身负载情况来调整上游向其发送数据的速率。
为了解决上述技术问题本发明提供如下的技术方案:
一种面向实时流计算的动态逐级反压方法,包括以下步骤:
步骤(1)遍历当前需要进行反压的任务Task集合Ti;
步骤(2)若Ti为空,则结束,否则Ti取出下一个Taski并将其从Ti中移除;
步骤(3)判断Taski是否处于过载,若是进行步骤(4),否则进行步骤(9);
步骤(4)获取Taski的上游节点集合U;
步骤(5)判断U是否为空,若为空则返回步骤(2),否则U取出下一个Ui并将其从U中移除,并进行步骤(6);
步骤(6)判断Ui节点是否正在进行反压,若是返回步骤(5),否则进行步骤(7)~(8);
步骤(7)Ui节点的发射速度降为当前的V’,V’为系统预设的反压梯值。若Ui是第一次反压,则记录Ui的初始速度originV,并保存到Ui本地;
步骤(8)Ui节点将自身反压状态设置为True,返回步骤(5);
步骤(9)判断Taski是否负载过轻且持续sentivity,若是则进行步骤(10),否则进行步骤(2),sentivity为系统预设的敏感度值;
步骤(10)获取Taski的上游节点集合U;
步骤(11)若U为空,返回步骤(2),否则U取出下一个节点Ui并将其从U中移除;
步骤(12)判断Ui节点是否处于反压状态,若反压状态为True,则进行步骤(13),否则返回步骤(11);
步骤(13)Ui节点的发射速度降为当前的1/V’;
步骤(14)判断Ui是否恢复到最初始的速度originV,若是则进行步骤(15),否则进行步骤(11);
步骤(15)Ui节点将自身反压状态设置为False,返回步骤(11)。
本发明的有益效果是,当某一Task过载导致延迟增加,上游的Bolt会减缓向下游发射的速率,更多的资源会被用来处理当前的正在处理的数据上,避免因阻塞、数据超时、重发等导致的延迟增加。当Task的负载降低至最小阈值且持续sensitivity秒,Task会向上游发送取消反压信号,上游Task收到取消反压信号后首先会检查自身是否处于反压状态,若是则会恢复上一次的发射速度(当前速度的1/V’),只有当组件恢复至初试速度时才会消除反压状态。迭代地进行反压/取消反压和使用定时器的原因都是为了抑制反压导致的负载振荡。该方法的主要优点是:1)无需设置额外的监控节点;2)当前组件只负责向直接上游反压,减少了拓扑中单个任务对整体延迟的影响;3)反压过程平滑,系统不会出现负载振荡。
附图说明
图1是本发明实施例中拓扑任务(Task)组件示意图。
图2是本发明实施例中Zookeeper消息队列示意图。
图3是本发明实施例中任务(Task)通信模型示意图。
图4是本发明实施例中动态逐级反压流程示意图。
图5是本发明实施例中动态逐级反压结构示意图。
具体实施方式
为使本发明的上述特征和过程更加明显易懂,下文特举实施例,并配合附图作详细说明如下。
图1为本发明实施例中拓扑任务(Task)组件示意图。如图1所示,拓扑中的每个当前组件C(Spout或者Bolt),在输入数据流i后,触发相关的操作fv,产生新的数据流t发送给下游组件,并根据自身反压信号将状态从S改变到S’(若状态不变,则S=S’),用公式表示即为(S’,t)=fv(S,i)。
本实施例中Task之间通信的消息队列通过Zookeeper实现,图2是本发明实施例中Zookeeper消息队列。如图2所示,该消息队列提供了异步通信协议的先入先出(FIFO)队列,消息的发送者Subject和接收者Observer不需要同时与消息队列交互,Subject的PUT操作用于向队列插入元素,Observer的GET操作用于从队列取出元素。图中1~6的方块表示数据的插入顺序,先插入的数据(数字小)会首先被GET操作取出。
基于Task通信消息队列,实现了Task之间的通信模型。图3是本发明实施例中任务(Task)通信模型示意图,如图3所示,当Taski与其上游Ui进行通信时,其流程如下:
(1)Taski将反压信号发送到send-queue队列;
(2)znode-create-handler线程订阅到send-queue消费消息,根据消息内容在Zookeeper的/taskmessage目录下创建节点;
(3)znode-delete-handler线程监听/taskmessage目录,并负责消费目录下的消息并将消息发送至trigger-queue,每消费一个节点后将其删除;
(4)Ui订阅到trigger-queue消费消息,根据消息内容作相关操作,如反压等;
(5)receive-thread负责接收Ui的状态信息并更新至Zookeeper的/taskstate目录;
(6)所有的Task均监听/taskstate目录,当目录有变化时,相应的Task会收到通知并作相关操作。
反压实质上是当下游组件处理不过来时促使上游组件尽量减缓消息的传入,使得整个Topology不会出现因消息阻塞而导致数据丢失和Topology过载或不稳定的机制。运算组件Bolt在收到上游的一个数据时会调用相关的计算方法,在该方法中嵌入基于流量动态逐级反压方法,灵敏度时间参数sensitivity,即至少经过sensitivity毫秒调用一次动态逐级反压方法。Tasks之间的反压信号通过Zookeeper消息队列通信,这种异步方式可能会导致下游Task的统计信息与上游Task统计信息有轻微不一致的情况,但是这种不一致性不影响正确性。
图4是本发明实施例中动态逐级反压流程示意图,不同的Bolt会根据自身流量独立进行反压调整。如图4所示,结合图3,动态逐级反压方法详细步骤如下:
步骤(1)遍历当前需要进行反压的Task集合Ti。
步骤(2)若Ti为空,则结束,否则Ti取出下一个Taski并将其从Ti中移除;
步骤(3)判断Taski的缓存队列是否到达最大阈值,最大阈值设置为50M,若是则判定该Taski处于过载状态,进行步骤(4),否则进行步骤(9);
步骤(4)获取Taski的上游节点集合U;
步骤(5)若U为空,返回步骤(2),否则U取出下一个节点Ui并将其从U中移除;
步骤(6)判断Ui节点是否正在进行反压,若没有正在进行反压,则进行步骤(7)~(8),若正在进行反压,则进行步骤(5);
步骤(7)Ui节点的发射速度降为当前的V’,V’为系统预设的反压梯值。若Ui是第一次反压,则记录Ui的初始速度originV,并保存到Ui本地,过程如下:
7.1)将反压信号和Ui的taskid发送到send-queue队列,taskid是节点的唯一标识;
7.2)znode-create-handler线程获得send-queue的反压信号和taskid,根据消息内容在Zookeeper的/taskmessage目录下创建文件节点;
7.3)znode-delete-handler线程监听/taskmessage目录的文件节点,从文件节点内容读取反压信号和taskis并发送到trigger-queue队列,然后将该文件节点删除;
7.4)Ui订阅到trigger-queue,获取并删除与自身taskid相同的反压信号;
7.5)Ui节点的发射速度降为当前的V’,V’为系统预设的反压梯值。若是Ui第一次反压,则记录Ui的初始速度originV,并保存到Ui本地;
步骤(8)Ui节点将自身反压状态设置为True,返回步骤(5);
步骤(9)判断Taski的缓存队列是否到达最低阈值且持续sentivity,最低阈值设置为500kb。sentivity为系统预设的敏感度值,设置为2000毫秒。若是则表示负载过轻,进行步骤(10),否则返回步骤(2);
步骤(10)获取Taski的上游节点集合U;
步骤(11)若U为空,返回步骤(2),否则U取出下一个节点Ui并将其从U中移除;
步骤(12)判断Ui节点是否处于反压状态,若反压状态为True,则进行步骤(13),否则返回步骤(11)
步骤(13)Ui节点的发射速度降为当前的1/V’,过程如下:
13.1)将取消反压信号和Ui的taskid发送到send-queue队列;
13.1)znode-create-handler线程获得send-queue的取消反压信号和taskid,根据消息内容在Zookeeper的/taskmessage目录下创建文件节点;
13.2)znode-delete-handler线程监听/taskmessage目录的文件节点,从文件节点内容读取反压信号和taskis并发送到trigger-queue队列,然后将该文件节点删除;
13.3)Ui订阅到trigger-queue,获取并删除与自身taskid相同的取消反压信号;
13.4)Ui节点的发射速度降为当前的1/V’;
步骤(14)判断Ui是否恢复到最初始的速度originV,若是则进行步骤(15),否则返回步骤(11);
步骤(15)Ui节点将自身反压状态设置为False,返回步骤(11)。
以上步骤的效果是,当某一Task过载时,上游的节点会减缓向下游发射的速率,更多的资源会被用来处理当前的正在处理的数据上,避免因阻塞、数据超时、重发等导致的延迟增加。当Task的负载降低至最小阈值且持续sensitivity毫秒,Task会向上游发送取消反压信号,上游Task收到取消反压信号后首先会检查自身是否处于反压状态,若是则会恢复上一次的发射速度(当前速度的1/V’),只有当组件恢复至初试速度时才会消除反压状态。迭代地进行反压/取消反压和使用定时器的原因都是为了抑制反压导致的负载振荡。
图5是本发明实施例中动态逐级反压结构示意图。如图5所示,当所有节点通过State保存节点状态信息,通过Trigger触发相关操作。因此,从整体结构上观察,反压步骤如下:
步骤(1)节点Spout/Bolt向下游发送一个数据(Tuple);
步骤(2)下游节点的当前节点处于过载状态;
步骤(3)当前节点Trigger触发反压,通过Zookeeper向上游传递反压信号;
步骤(4)Zookeeper接收反并持久化反压信号。
步骤(5)BackPressure-Cordinator-Handler监听到Zookeeper的反压信号后获取并删除该信号,同时向节点发送反压。
步骤(6)收到反压信号的节点的Trigger被触发,调整发射数据的速率后修改State状态。
Claims (3)
1.一种面向实时流计算的动态逐级反压方法,其特征在于:包括以下步骤:
步骤(1)遍历当前需要进行反压的任务Task集合Ti;
步骤(2)若Ti为空,则结束,否则Ti取出下一个Taski并将其从Ti中移除;
步骤(3)判断Taski是否处于过载,若是进行步骤(4),否则进行步骤(9);
步骤(4)获取Taski的上游节点集合U;
步骤(5)判断U是否为空,若为空则返回步骤(2),否则U取出下一个Ui并将其从U中移除,并进行步骤(6);
步骤(6)判断Ui节点是否正在进行反压,若是返回步骤(5),否则进行步骤(7)~(8);
步骤(7)Ui节点的发射速度降为当前的V’,V’为系统预设的反压梯值;若Ui是第一次反压,则记录Ui的初始速度originV,并保存到Ui本地;
步骤(8)Ui节点将自身反压状态设置为True,返回步骤(5);
步骤(9)判断Taski是否负载过轻且持续sentivity,若是则进行步骤(10),否则进行步骤(2),sentivity为系统预设的敏感度值;
步骤(10)获取Taski的上游节点集合U;
步骤(11)若U为空,返回步骤(2),否则U取出下一个节点Ui并将其从U中移除;
步骤(12)判断Ui节点是否处于反压状态,若反压状态为True,则进行步骤(13),否则返回步骤(11);
步骤(13)Ui节点的发射速度降为当前的1/V’;
步骤(14)判断Ui是否恢复到最初始的速度originV,若是则进行步骤(15),否则进行步骤(11);
步骤(15)Ui节点将自身反压状态设置为False,返回步骤(11)。
2.如权利要求1所述的一种面向实时流计算的动态逐级反压方法,其特征在于:所述步骤(7)的过程如下:
7.1)将反压信号和Ui的taskid发送到send-queue队列,taskid是节点的唯一标识;
7.2)znode-create-handler线程获得send-queue的反压信号和taskid,根据消息内容在Zookeeper的/taskmessage目录下创建文件节点;
7.3)znode-delete-handler线程监听/taskmessage目录的文件节点,从文件节点内容读取反压信号和taskis并发送到trigger-queue队列,然后将该文件节点删除;
7.4)Ui订阅到trigger-queue,获取并删除与自身taskid相同的反压信号;
7.5)Ui节点的发射速度降为当前的V’,V’为系统预设的反压梯值;若是Ui第一次反压,则记录Ui的初始速度originV,并保存到Ui本地。
3.如权利要求1或2所述的一种面向实时流计算的动态逐级反压方法,其特征在于:所述步骤(13)的过程如下:
13.1)将取消反压信号和Ui的taskid发送到send-queue队列;
13.1)znode-create-handler线程获得send-queue的取消反压信号和taskid,根据消息内容在Zookeeper的/taskmessage目录下创建文件节点;
13.2)znode-delete-handler线程监听/taskmessage目录的文件节点,从文件节点内容读取反压信号和taskis并发送到trigger-queue队列,然后将该文件节点删除;
13.3)Ui订阅到trigger-queue,获取并删除与自身taskid相同的取消反压信号;
13.4)Ui节点的发射速度降为当前的1/V’。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710140963.5A CN107040476B (zh) | 2017-03-10 | 2017-03-10 | 一种面向实时流计算的动态逐级反压方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710140963.5A CN107040476B (zh) | 2017-03-10 | 2017-03-10 | 一种面向实时流计算的动态逐级反压方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107040476A true CN107040476A (zh) | 2017-08-11 |
CN107040476B CN107040476B (zh) | 2020-05-05 |
Family
ID=59533580
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710140963.5A Active CN107040476B (zh) | 2017-03-10 | 2017-03-10 | 一种面向实时流计算的动态逐级反压方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107040476B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113127221A (zh) * | 2019-12-31 | 2021-07-16 | 奇安信科技集团股份有限公司 | 一种限制消息消费速率的方法、装置、设备及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103188345A (zh) * | 2013-03-01 | 2013-07-03 | 北京邮电大学 | 分布式动态负载管理系统和方法 |
US20160269247A1 (en) * | 2015-03-13 | 2016-09-15 | Nec Laboratories America, Inc. | Accelerating stream processing by dynamic network aware topology re-optimization |
CN106375416A (zh) * | 2016-08-30 | 2017-02-01 | 北京航空航天大学 | 分布式数据存储系统中一致性动态调整方法及装置 |
-
2017
- 2017-03-10 CN CN201710140963.5A patent/CN107040476B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103188345A (zh) * | 2013-03-01 | 2013-07-03 | 北京邮电大学 | 分布式动态负载管理系统和方法 |
US20160269247A1 (en) * | 2015-03-13 | 2016-09-15 | Nec Laboratories America, Inc. | Accelerating stream processing by dynamic network aware topology re-optimization |
CN106375416A (zh) * | 2016-08-30 | 2017-02-01 | 北京航空航天大学 | 分布式数据存储系统中一致性动态调整方法及装置 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113127221A (zh) * | 2019-12-31 | 2021-07-16 | 奇安信科技集团股份有限公司 | 一种限制消息消费速率的方法、装置、设备及存储介质 |
CN113127221B (zh) * | 2019-12-31 | 2024-06-07 | 奇安信科技集团股份有限公司 | 一种限制消息消费速率的方法、装置、设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN107040476B (zh) | 2020-05-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105432046B (zh) | 用于数据流的快速友好启动的方法、装置及介质 | |
US9800483B2 (en) | Method and apparatus for dynamic bandwidth allocation for optimizing network utilization | |
EP2456142A1 (en) | Methods and apparatus for detecting and limiting focused server overload in a network | |
US11095568B2 (en) | Systems and methods for network scheduling and re-transmission buffering | |
CN103999414B (zh) | 一种归因针对相应用户寄存器的共享资源的拥塞贡献的方法和装置 | |
CN113992588B (zh) | 数据传输方法、装置、电子设备及可读存储介质 | |
CN104995883B (zh) | 用信号通知拥塞的方法 | |
CN106936730A (zh) | 一种报文发送方法、tcp代理以及tcp客户端 | |
CN103746938A (zh) | 一种发送数据包的方法及装置 | |
CN102724123A (zh) | 网络流量控制方法及控制装置 | |
US20220368606A1 (en) | Fault Detection Model Training Method, Apparatus, and System | |
Abu et al. | A markov model of CCN pending interest table occupancy with interest timeout and retries | |
CN112787942A (zh) | 一种tcp拥塞控制方法、装置、终端及可读存储介质 | |
Wu et al. | Analysis of the energy-response time tradeoff for delayed mobile cloud offloading | |
CN107040476A (zh) | 一种面向实时流计算的动态逐级反压方法 | |
Argibay-Losada et al. | Transport-layer control to increase throughput in bufferless optical packet-switching networks | |
US8055782B2 (en) | System and method for generating exception delay messages when messages are delayed | |
CN106789709B (zh) | 一种负载均衡的方法及装置 | |
Melo et al. | An overview of self-similar traffic: Its implications in the network design | |
CN112350954B (zh) | 过载保护方法、系统、计算机可读存储介质及电子设备 | |
Argibay-Losada et al. | Optical versus electronic packet switching in delay-sensitive 5G networks: myths versus advantages | |
CN109450941B (zh) | 一种抗DDoS的SDN控制器消息调度方法 | |
CN106453635B (zh) | 消息推送方法及装置 | |
CN115914115A (zh) | 网络拥塞控制方法、装置及通信系统 | |
Xie et al. | Shared bottleneck detection for multipath transmission in high latency satellite network |
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 |