规范解读GB28181-2016和GB28181-2022关于媒体保活机制这块,并无调整,平台、设备媒体流保活机制规定如下:a)链路建立后,码流经过的各级平台应具备媒体流丢失监测能力,若监测到媒体流丢失 ,应释放该条媒体链路,并通过会话内Bye消息通知上下级平台;b)上下级平台之间、平台与设备之间、平台与客户端之间应通过注册,状态信息报送等进行状态监测,若监测到媒体流接收方或媒体流发送方故障或离线,应主动释放媒体链路 下级平台,设备在接收到呼叫请求后,应判断是否在发送以此媒体源标识的码流,若已经在发送,则应释放现有媒体流发送链路并按照请求建立新的媒体流发送链路。 技术实现本文以大牛直播SDK的Android平台GB28181设备接入模块为例,启动GB28181即注册到国标平台侧,并按照周期发送信条信令:图片和心跳相关的参数设置如下:private int gb28181 媒体保活机制,相对比较清晰,不会有大的规范解读误区,感兴趣的开发者,可以参考实现。
前言 目前实际项目对接遇见很多平台级联过程中,视频流有类似rtsp一样的rtcp保活机制,随翻看国标GB28181-2016协议文档,查阅相关说明,现分享如下。 协议原文 平台、设备媒体流保活机制 贴张协议文档规范截图 见解 根据协议描述中介绍,国标暂未规定视频流的rtcp保活,这块还是各个视频厂家自己定义的保活手段,如遇见rtcp保活手段的方式,可参考rtsp 的保活方法。
3.高效维持长连接方案 进程保活(防止进程被杀死) 心跳保活(阻止NAT老化) 断线重连(断网以后重新连接网络) 3.1 进程保活 ? 进程保活.jpg 3.2 心跳保活 第4节会说明 3.3 断线重连 需要检测网络状态&监听网络变化,可以考虑BroadcastReceiver 4.心跳保活 4.1 定义 每隔一段时间想对方发送自定义信息 (心跳包),以确保连接存活且有效的通信机制 注意,它和和轮询机制区别:一次轮询相当于一次TCP连接和断开 4.2 心跳机制的方案和设计 ? 心跳流程.jpg 4.3 设计要点 心跳包的规格(内容 & 大小) 心跳发送的间隔时间 断线重连机制 4.3 (1)心跳包的规格 心跳包 = 1个携带少量信息 & 大小在10字节内的信息包 4.3 (2 NAT 超时时间的心跳间隔时间 (2)如何检测 当前网络环境的NAT 超时时间 发生了变化 当前发送心跳包成功 的最大间隔时间(即最接近NAT超时时间的心跳间隔) 发送失败5次后 4.3 (3)断线重连机制
文章目录 一、Low Memory Killer 机制 二、Low Memory Killer 参数 一、Low Memory Killer 机制 ---- Android 中有一套 Low Memory Killer 机制 , 应用退出后 , 其进程不会马上被杀死 , 而是缓存起来 ; 如下图所示 , 点击回退键 , 使应用退出后 , 然后点击 Menu 键 , 从任务栈列表中扔可以看到退出的应用 , 此时点击该任务栈 , 仍可以将该应用拉起到前台 ; 打开应用越多 , 后台缓存的应用也就越多 ; 如果出现内存不足的情况 , 系统会根据 Low Memory Killer 机制 判定哪些进程被回收 , 为新的进程提供充足的内存 ; 二、Low Memory Killer 参数 ---- 查看 Android 设备中的 Low Memory Killer 机制 相关参数 ; 进入 Android
前言 当实现具备实时性需求时,我们一般会选择长连接的通信方式 而在实现长连接方式时,存在很多性能问题,如 长连接保活 今天,我将 手把手教大家实现自适应的心跳保活机制,从而能高效维持长连接 目录 1 断线重连:断了之后继续重连回来 解决方案1:进程保活 整体概括如下: 解决方案2:心跳保活机制 这是本文的重点,下节开始会详细解析 解决方案3:断线重连机制 原理 检测网络状态变化 & 判断连接的有效性 具体实现 前者请参考文章:Android:检测网络状态&监听网络变化;后者主要存在于心跳保活机制,所以下面会在心跳保活机制中一起讲解。 心跳保活机制简介 心跳保活机制的整体介绍如下 注:很多人容易混淆 心跳机制 & 轮询机制,此处给出二者区别 5. 额外说明:TCP 协议自带 KeepAlive 的机制 是否 可替代心跳机制 很多人认为,TCP 协议自身就有KeepAlive机制,为何基于它的通讯链接,仍需 在应用层实现额外的心跳保活机制?
文章目录 一、 双进程守护保活原理 二、 双进程守护保活完整源码 1、AIDL 接口 2、本地前台服务 Service 3、远程前台服务 Service 4、清单配置 5、启动两个服务 5、执行效果 三、 源码资源 一、 双进程守护保活原理 ---- 双进程守护拉活 , 使用 JobScheduler 拉活 和 系统 Service 机制拉活 两种拉活方式 , 结合起来使用 ; 双进程机制拉活 , 比之前的 广播拉活 , 系统 Service 机制拉活 , 账户同步拉活 , JobScheduler 机制拉活 , 成功率都要高 , 可靠性比较高 , 但是也存在失败的情况 ; JobScheduler // 通信内容 } } " 本地前台进程 " LocalForegroundService 在 onCreate 方法中开启前台服务 , 提权 , 参考 【Android 进程保活 android.permission.FOREGROUND_SERVICE 权限 : <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> 二、 双进程守护保活完整源码
TCP保活报文格式: 1, TCP keepalive probe报文 我们看到,TCP保活探测报文是将之前TCP报文的序列号减1,并设置1个字节,内容为“00”的应用层数据,如下图所示: TCP keepalive ACK报文 TCP保活报文交互过程 TCP保活的交互过程大致如下图所示: ? TCP保活可能带来的问题 1, 中间设备因大量保活连接,导致其连接表满 网关设备由于保活问题,导致其连接表满,无法新建连接(XX局网闸故障案例)或性能下降严重 2, 正常连接被释放 TCP保活的设置 一般而言,保活探测主要在服务器端实现,如果应用层有相应的保活机制时,传输层的TCP保活就可以不用。 如果远程系统仍然可以连接并且正在运行,它就会响应保活传输。默认情况下不发送保活数据包。应用程序可以在连接上启用此功能。
Python线程的保活主要是确保线程在执行过程中不被意外中断或终止。 使用适当的同步机制:除了锁之外,还可以使用其他同步机制来协调线程之间的操作,如条件变量(threading.Condition)、信号量(threading.Semaphore)和事件(threading.Event 这些同步机制可以帮助你避免死锁和活锁等问题。 定期检查线程状态:你可以定期检查线程的状态,以确保它们仍在运行。如果发现某个线程停止运行或出现异常,你可以重新启动它或采取相应的措施。
文章目录 一、android进程的优先级 二、android进程的回收策略 三、进程保活方案 1、利用系统广播拉活 2、利用系统Service机制拉活 3、利用native进程拉活 4、 利用JobScheduler 机制拉活 5、利用账户同步机制拉活 一、android进程的优先级 二、android进程的回收策略 三、进程保活方案 1、利用系统广播拉活 缺点: 1)、系统广播不可控,只有在系统广播发生的时候能重启 2、利用系统Service机制拉活 在service中有一个onStartCommend(),将返回值设置为start_stick(当service因系统内存不足被杀死时,在系统内存充足时重新启动service 3、利用native进程拉活 利用linux 中fork机制创建一个native进程,在native进程可以监控主进程的存活, 当主进程挂掉后,可以立即对主进程拉活,主要利用的就是android里面的 主要是am命令 4、 利用JobScheduler机制拉活 会监听主进程 5、利用账户同步机制拉活 最新版本对账户同步改动了,估计不行了。
解决这个问题的办法比较简单,程序只要定期给 MySQL 发送请求,表示自己还活着,MySQL 就不会触发断开连接的操作了,这就是数据库连接保活的应用场景。 今天我们来聊聊数据库连接保活的原理和方式。 两种保活方式对比 6. 总结 正文 1. 所以,ping 命令不但可以用于数据库连接探活,还可以用于保活。 … 执行 select 语句保活,和正常执行业务 SQL 没什么区别,这里不展开了。 两种保活方式对比 既然 ping 和 select 都能实现数据库连接保活,那它们之间有什么不一样?
onStartCommand 函数 START_NOT_STICKY 返回值 5、 onStartCommand 函数 START_REDELIVER_INTENT 返回值 二、 系统 Service 机制拉活 1、 Service 代码 2、 清单配置 3、启动服务 三、 测试效果 四、 系统 Service 机制拉活总结 五、 源码资源 一、 Service 组件 onStartCommand 方法分析 使用 Service 机制拉活 startService(new Intent(this, StickService.class)); } @Override ---- 系统 Service 机制拉活 , 不是 100% 有效 , 有一定成功几率 ; 有些机型 ROM , 拉活无效 ; 测试的 Google Pixel2 Android 10 可以拉活 ; 有相当大的一部分手机不支持该 Service 机制拉活 ; ( 是否支持 , 与系统有关 , 与手机厂商有关 ) 每次杀掉 Service 所在应用进程 , 重启都比上一次慢 , 大约杀掉几次进程后 (
第23章 TCP的保活定时器 23.3 保活举例 现在详细讨论前一节提到的第 2、3和4种情况。我们将在使用这个选项的情况下检查所交换的分组。 客户使用- K选项使能保活功能。 • 验证数据可以通过该连接。 • 观察客户T C P每隔2小时发送保活分组,并观察被服务器的 T C P确认。 • 我们预期服务器在断定连接已中断前发送 1 0个间隔为7 5秒的保活探查。 这里是客户端的交互输出结果: ? 第6行的保活探查引出来自另一端的响应(第 7行)。两个小时以后,在第7和8行发生了同样的分组交换过程。 两个小时之后,客户发送第1个保活探查,其响应是一个来自服务器的复位。客户应用进程打印出“连接被对端复位”的差错,这是有意义的。
近期就有技术人员在平台测试时发现:在LiteCVR上如果用命令进行保活的话,前端频繁操作查看历史流,就会出现很多无效历史流的问题。 安防视频监控LiteCVR平台可拓展性强、视频能力灵活、部署轻快,可支持的主流标准协议有国标GB28181、RTSP/Onvif、RTMP等,以及支持厂家私有协议与SDK接入,包括海康Ehome、海大宇等设备的 如遇此类问题,可根据下面步骤进行操作解决:1)首先用nginx反向代理,双发.m3u8的连接,一路给后台作保活,一路给前端.m3u8播放,这样就可做到不播放就不保活;2)具体流程如下图:3)根据以上操作执行后 ,再用上级平台播放即可做到自带保活。 音视频流媒体视频平台LiteCVR拓展性强,视频能力丰富,平台既具备传统安防视频监控的能力,也具备接入AI智能分析的能力,可拓展性强、视频能力灵活,能对外分发RTMP、RTSP、HTTP-FLV、WebSocket-FLV
这些因素都影响了拉活的效果。 4.3. 利用系统Service机制拉活 4.3.1. 方案设计思想 将 Service 设置为 START_STICKY,利用系统机制在 Service 挂掉后自动拉活: ? 4.3.2. 方案设计思想 主要思想:利用 Linux 中的 fork 机制创建 Native 进程,在 Native 进程中监控主进程的存活,当主进程挂掉后,在 Native 进程中立即对主进程进行拉活。 利用 JobScheduler 机制拉活 4.5.1. 方案设计思想 Android5.0 以后系统对 Native 进程等加强了管理,Native 拉活方式失效。 仅在小米手机可能会出现有时无法拉活的问题。 4.6. 利用账号同步机制拉活 4.6.1. 方案设计思想 Android 系统的账号同步机制会定期同步账号进行,该方案目的在于利用同步机制进行进程的拉活。
中的定时器和 System.Timers.Timer 的工作方式是完全一样的,所以,这里我们仅讨论 System.Timers.Timer 和 System.Threading.Timer 1、定时器保活 这就是定时器的 保活机制,因为定时器需要执行 timer_Elapsed 方法,而该方法属于 Foo 实例,所以 Foo 实例被保活了。 但是如果在 Stop 方法之后又调用了 Start 方法,那么对象依然会被保活,即便 Stop 之后进行强制垃圾回收,也无法回收对象。 System.Timers.Timer 和 System.Threading.Timer 的保活机制是类似的。 保活机制是由于定时器引用了实例中的方法,那么,如果定时器不引用实例中的方法呢? 2、不保活下 System.Timers.Timer 和 System.Threading.Timer 的差异 要消除定时器对实例方法的引用也很简单,将 timer_Elapsed 方法改成 静态 的就好了
文章目录 一、 双进程守护保活 + JobScheduler 原理 二、 双进程守护保活 + JobScheduler 源码 1、JobService 代码 2、判定服务运行工具类 3、清单文件 4、 MainActivity 代码 5、运行效果 三、 源码资源 一、 双进程守护保活 + JobScheduler 原理 ---- 【Android 进程保活】应用进程拉活 ( JobScheduler 拉活 | JobScheduler 使用流程 | JobService 服务 | 不同版本兼容 | 源码资源 ) 博客中介绍了 JobScheduler 的用法 ; 【Android 进程保活】应用进程拉活 ( 双进程守护保活 ) 博客中介绍了双进程守护保活用法 ; 使用 " 双进程守护保活 + JobScheduler " 机制 , 成功率最高 ; " 双进程守护保活 + JobScheduler " + JobScheduler 源码 ---- 大部分代码与 【Android 进程保活】应用进程拉活 ( 双进程守护保活 ) 博客中重复 , 这里只贴出 JobScheduler 相关源码 ; 1、JobService
了解我们产品的用户知道,作为音视频流媒体行业的视频能力平台设计者,我们的产品不限设备品牌只要协议支持就可以接入做流转换,其中EasyNVR主要作为RTSP协议设备/平台接入,EasyGBS主要作为GB28181 EasyNVR也可以级联其他支持GB28181协议的平台,有时级联到上级平台后,开启按需通道多屏播放,如果发送级联停止消息使播放器停止播放一路视频时,其它视频也会同时被停止播放。 我们排查了一下视频流,流在EasyNVR平台播放时正常,没有出现中断现象,说明流正常,那就有可能是保活机制的问题,在级联保活的地方打断点调试发现当上级平台发送停止消息关闭了定时器后其它通道的保活也都停止了 ,查找代码发现保活的定时器是全局共用一个的,定时器关闭后所有的保活都会受到影响。
了解我们产品的用户知道,作为音视频流媒体行业的视频能力平台设计者,我们的产品不限设备品牌只要协议支持就可以接入做流转换,其中EasyNVR主要作为RTSP协议设备/平台接入,EasyGBS主要作为GB28181 image.png EasyNVR也可以级联其他支持GB28181协议的平台,有时级联到上级平台后,开启按需通道多屏播放,如果发送级联停止消息使播放器停止播放一路视频时,其它视频也会同时被停止播放。 image.png 我们排查了一下视频流,流在EasyNVR平台播放时正常,没有出现中断现象,说明流正常,那就有可能是保活机制的问题,在级联保活的地方打断点调试发现当上级平台发送停止消息关闭了定时器后其它通道的保活也都停止了 ,查找代码发现保活的定时器是全局共用一个的,定时器关闭后所有的保活都会受到影响。
本文从心跳机制与状态恢复两个维度,解析企业微信协议接口的保活设计。 企业微信ipad协议的登录态维护采用双ticket机制:Sid用于维持TCP长连接,有效期24小时;Tgt用于断线重连时免扫码恢复,有效期30天。 心跳机制的另一个重要场景是群聊状态的实时感知。企业微信ipad协议通过长连接推送群事件,客户端需在收到member_kick、group_rename等事件后更新本地缓存。
TSINGSEE青犀近日发布了EasyCVR安防管理平台的V.3.4版本,其中一大亮点就是很多朋友都在咨询的“免保活”功能,那么,什么是“免保活”功能?又该如何配置呢? 所以,在调用API集成直播流时必须添加保活接口,在需要播流的时间内,定时触发直播流接口,即客户端向应用层持续发送心跳,以保证流地址可用。 而国标GB28181安防视频系统EasyCVR平台V.3.4版本加入了免保活功能,兼顾了这两种使用场景。 使用只需在easycvr.ini配置文件中找到“check_keepalive_time”,默认为 0 ,即不开启;配置保活时间(25-30s)则启用。