1006. 连通性问题

1006. 连通性问题
 
 
Total:58 Accepted:19
 
     
     
 
Time Limit: 5sec    Memory Limit:256MB
Description
关系R具有对称性和传递性。数对p q表示pRq,p和q是0或自然数,p不等于q。
要求写一个程序将数对序列进行过滤,如果一个数对可以通过前面数对的传递性得到,则将其滤去。例如:
输入    输出 	  连通性
3 4      3 4    
4 9      4 9
8 0      8 0
2 3      2 3
5 6      5 6
2 9                     2-3-4-9
5 9      5 9
7 3      7 3
4 8      4 8
5 6                     5-6
0 2                     0-8-4-3-2
6 1      6 1

 其中数对2 9和0 2可由之前数对的连通关系得到,故不做输出。

Input

输入共有m行(0<=m<=1000000),每行一个数对,数对的数字之间以1个空格分隔;数对的数字为0或n=100000以内的自然数。
 

Output

输出包含过滤之后的数对序列。每行输出一个数对,数对的数字之间以1个空格分隔。
 

Sample Input
 Copy sample input to clipboard
3 4
4 9
8 0
2 3
5 6
2 9
5 9
7 3
4 8
5 6
0 2
6 1
Sample Output
3 4
4 9
8 0
2 3
5 6
5 9
7 3
4 8
6 1

Problem Source: Disjoint Sets

根据我给你的内容,归纳测试点:给出个表格 按稳定性 功能 性能 跨模块影响四个方面给出 然后再总结个mermaid的测试点梳理导图 按稳定性 功能 性能 跨模块影响四个方面给出,需要体现测试设计中的等价类以及路径覆盖,正交表法等测试设计原则 1.1.1 推流原理 原有https推流逻辑如下图所示: 设备oboarding以及Camera已绑定到Hub并开启hub storage功能之后,APPCamera交互,确认hub storage功能处于开启状态,Camera将侦测流发送到Hub保存。 Camera触发侦测时,与Hub建立HTTPS连接(Hub监听21443端口),推送侦测事件(snapshot)以及侦测流(alarm stream),每个事件采用独立的HTTPS短连接发送。如果推流连接创建失败,则回退到原有逻辑,根据当前功能开关Camera自行上报推送,上传clips将视频流存储到SD卡。 在上述交互流程的基础上引入传输中对quic协议的支持,整体的交互流程如下图所示: 本模块交互流程的前置条件是 App 已完成 Onboarding 以及 Cam–Hub 绑定。后续: 1. 建立长连接并进行能力集判断(是否启用 quic_enable=1)。 2. 若连接成功,检测网络状态变化;如失败则重建长连接。 3. 在连接稳定后执行连通性测试,测试成功则可使用 QUIC。 4. 当 Cam 触发侦测事件(如MD运动检测)时,会通过向 Hub 发送推流请求 (StorageHubRequest)。 5. Hub 监听端口 22443 接收请求,并根据能力集 + 连通性测试结果选择协议进行推流(QUIC HTTPS)。 测试点:  能力集判断逻辑 ,即能力集字段的bit位内容quic_enable=1/0的对应关系,验证后续根据quic_enable进行协议选择的逻辑是否正常  连通性测试触发时机,验证长连接建立后是否自动触发测试,失败后是否有重试逻辑,重试逻辑是否符合指退避的测试思想  协议切换正确,QUIC失败后能否回退HTTPS,并在网络恢复后重新启用QUIC  长连接的重建,模拟网络波动、样机Cam者Hub重启、Token过期,观察Hub者Cam是否能自动重连并维持连接状态  协议建连性能,同弱网环境下对比QUIC与HTTPS建连耗时  长连接带宽利用率,记录长时间运行下的QUIC/HTTPS占比及吞吐率  Hub与云交互致性 ,验证协议切换影响Hub代理Cam上云的流程 1.1.2 版本协商(能力集) 能力集:版本协商机制中提供的个字段,表明设备对功能的支持状态,本模块在长连接的请求中使用本字段进行设备间的支持情况沟通。 Cam与Hub的版本协商机制旨在解决新旧固件的设备在功能支持致时的兼容性问题,特别是在引入支持双目Camera等新功能后,确保只有能力匹配的设备才能成功绑定,避免因协议功能兼容导致的异常。版本协商的核心机制有两点: 1. 设备发现阶段的广播包增加hub_cam_capability字段(即能力集:表示设备对新功能的支持状态),设备间会进行能力集的交换。 2. 设备(HubCam)基于双方能力集来计算bind_check值,该值决定设备间是否允许绑定。 1) 版本协商的交互流程(说明hub主动发现cam主动发现的区别) 版本协商处于广播发现的流程中,广播发现分Camera主动发现Hub主动发现 2) 能力集(本模块使用的核心字段) 能力集是个位图(Bitmap)字段,用于在发现阶段交换设备的功能支持情况。 上述的广播报文以及响应的单播报文中会携带 每个bit代表项特定的能力,从低位开始依次定义如下: Bit 功能含义 是否影响绑定 0 支持 OPUS 音频编码 否(可降级) 1 支持双目 Camera 接入 是(强制要求) 2 支持 QUIC 推流至 Hub 否(可降级) … … … 本模块功能在能力集字段中的Bit位为2,取值状态对应如下: 1. Bit位为0:本设备支持该功能 2. Bit位为1:本设备支持该功能 并且本模块功能的支持与否并影响绑定的判定结果。 3) bind_check 错误码 bind_check是设备收到广播发现报文后,在响应中返回的个状态码 错误码 含义 触发条件举例 1000 允许绑定 所有能力匹配可降级 1001 Hub 固件支持新功能 如 Hub 支持 bit1(双目),而 Cam 强制要求 1002 Cam 固件支持新功能 Cam 缺少必要bit位,无法满足 Hub 要求 1003 双方均支持 双方的必要bit位都是0 1004~1006 预留(部分异常但仍可绑定) 待扩展用于警告类提示 4) 根据绑定结果,将hubcamera进行绑定 同场景下的版本协商结果如下表 场景 描述 Cam主动发现中的流程 能力协商结果 quic_enable 旧 Hub + 旧 Cam (均无 capability 字段) 双方均为老版本固件 使用原始 TDP 协议,无能力字段交换 按基础功能运行,无法启用新特性(如 QUIC、双摄) 0 旧 Hub + 新 Cam (Hub 无字段,Cam 有字段) Cam 支持新功能,但 Hub 识别 Cam 发起发现 → Hub 回传中忽略 capability 字段,回传 Cam 检测到 Hub 能力 → 默认 Hub 支持新功能 → 降级运行拒绝绑定(视功能重要性) 0 新 Hub + 旧 Cam (Hub 有字段,Cam 无字段) Hub 支持新功能,Cam 未知 Cam 发起发现 → 带 capability 字段 → Hub 回复时仍携带自身 capability bind_check Hub 单方面判断兼容性 → 若依赖 Cam 能力(如 bit1),则返回 1002 错误码 → App 提示升级 Cam 固件 0 新 Hub + 新 Cam (双方都有 capability 字段) 完整支持能力协商 双向交换 capability 字段 → Hub 计算 bind_check → Cam 综合判断 全面分析功能启用状态(如 QUIC 是否开启)并判断是否能够绑定 1 5) 本模块中版本协商:长连接+能力集+连通性测试: 版本协商机制中提供的能力集字段在本模块中的作用:止存在于广播报文中,该字段还会在如下的交互中进行传递。 1. 长连接中的请求 2. Sync请求 3. StorageRequest请求 本质:版本协商机制定义的字段,即能力集,在协议选择的逻辑判断中会起到作用 该部分作为整体业务流程的第部分,有如下的关键业务流程步骤 1. Cam 通过 storageHubRequest 建立长连接; 2. 发送广播,通知Hub连接已建立; 3. Hub 接收广播后更新状态(long_connection=1),向Cam 同步; 4. Cam 在收到Hub报文后执行能力集判断; 5. 若 Hub 支持 QUIC (quic_enable=1),Cam 发起连通性测试; 6. 连通性测试成功后记录结果,用于后续推流协议选择。 测试点:  能力集字段解析,Hub端返回能力集字段时Cam是否正确解析,字段缺失值异常时对quic_enable的处理正确。  联通性测试正确性,测试请求是否发出、Hub响应是否按时返回、Cam是否能正确判定成功/失败  连通性测试的异常处理机制机制,Hub延迟响应丢包时,Cam是否能在设定超时内回退到HTTPS逻辑,并且采取指退避。  连通性测试状态影响,高频重建长连接以及持续触发侦测时,周期执行联通性测试是否导致样机内存CPU占用情况异常  能力集与版本协商,Hub与Cam对本模块同的支持情况是否会影响HubCam的绑定结果(版本兼容性测试)  本模块的新功能加入会影响版本协商过程中的绑定机制  长连接中的请求,最终输出的版本协商结果quic_enable输入的新旧Camera新旧Hub能对应上(如上表) 1.1.3 连通性测试 在本模块中,连通性测试测试的对象链路是:Camera推流到Hub这条链路 其中连通性测试若失败有指退避策略(见2.4.4): 连通性:需先测试连通性,由于QUIC是基于UDP的协议,可能线上某些环境存在UDP禁用等情况,因此需先进行连通性测试。确认可联调之后,才能开启QUIC协议。 当前设计中,在长连接状态发生变化,且变化后长连接状态为1,则开始进行连通性测试,测试通过的表现: QUIC连通性: >>>>>>>>>>>update link support<<<<<<<<<< link_type: hub hub_support_proto = 2(2表示QUIC可用,0表示可用) QUIC相关日志(建连): CLIENT_HANDSHAKE_TRAFFIC_SECRET e692f09cd5c0eb8af9d9e729eac7d2e034ac17e7d77955e1e7d9a09a700b29e1 34f37f8f0153447cf82ed4341f83b7db1434d33474c3b6bd54c1f27322cb81c0 SERVER_HANDSHAKE_TRAFFIC_SECRET e692f09cd5c0eb8af9d9e729eac7d2e034ac17e7d77955e1e7d9a09a700b29e1 6529017356a91bcde8b193ac79ce5cd82474be68a64e5655e68b259bd8151439 CLIENT_TRAFFIC_SECRET_0 e692f09cd5c0eb8af9d9e729eac7d2e034ac17e7d77955e1e7d9a09a700b29e1 6bceb3a22519083b30d72b4a47b303a48947c9d80668b0893f989a11e4b29005 SERVER_TRAFFIC_SECRET_0 e692f09cd5c0eb8af9d9e729eac7d2e034ac17e7d77955e1e7d9a09a700b29e1 7f1a2b9cb37b70609e8ccdfcf63e7bc2c67b749a8daf8dafbd7bdd8d37df39d5 连通性测试通过后,推snapshot首选使用quic,如果quic推snapshot失败,尝试使用https。接下来推alarm_stream时,尝试quic连接,如果quic连接失败,则进行降级,采用指退避策略重试,首次重试间隔为1h,最大重试间隔为24h(1,2,4,8,16,24),达到阈值后再重试。 连通性测试的详细设计如下: 测试点归纳: 1. 网络连接变化时\配置同步失败时,是否会重新触发连通性测试的逻辑 2. 上电后的长连接,会触发连通性测试的逻辑 1.1.4 降级策略 设计思想:连通性测试通过后,推snapshot首选使用quic,如果quic推snapshot失败,尝试使用https。接下来推alarm_stream时,尝试quic连接,如果quic连接失败,则进行降级,采用指退避策略重试,首次重试间隔为1h,最大重试间隔为24h(1,2,4,8,16,24),达到阈值后再重试。 在触发侦测+推送+推流交互流程中的详细降级策略: 测试点:  协议选择,触发侦测,验证Cam是否根据quic_enable与联通性结果选择正确协议  降级策略,构造QUIC推流成功HTTPS推流失败的场景,验证Cam是否自动降级到HTTPS并更新全局变量(表现为本次推流后续走HTTPS)  全局状态同步,验证alarm全局变量的值与实际推流协议致  频繁侦测触发测试,模拟高频侦测(>10次/分钟),观察Cam是否出现状态错乱  QUIC推流成功率,统计在同弱网环境下QUIC推流的视频留存率  回退与恢复时延 ,测量从QUIC失败→HTTPS与从HTTPS恢复→QUIC的平均耗时  Hub端端口监听,验证Hub 22443端口在QUIC/HTTPS切换时是否正常接收,( HTTPS所使用的端口同)
最新发布
11-05
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值