WebRTC技术在音视频领域已经证明了自己的强大,我们内部在使用中国节点的应用控制台时遇到报错

摘要2016年6月9日是开源实时音视频工程WebRTC开源5周年的日子,Google
WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展,并附上了自己5年前同样场景下写的一篇文章。前言2016年6月9日是WebRTC开源5周年的日子,Google
WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展,并附上了自己5年前同样场景下写的一篇文章。为了便于大家更好理解过去5年在WebRTC上都发生了什么,我将这两篇给翻译过来了。友情提醒:整个翻译并不是逐字逐句进行的,而是在理解了作者的意思后用自己的语言表达出来的,因为如果逐字逐句可能很多意思我们都无法正确理解。这就是为什么有些英文资料被翻译成中文后晦涩难懂。当然如果英语够好建议直接看原文。5年前的感慨今天谷歌开源了WebRTC技术,一个用于实时语音和视频通话的软件包,她即将被整合到Chrome。这是我们的第一波贡献,一切都是为了一个伟大的使命——在统一的标准的API下实现所有浏览器间的音视频通话。这个初始版本将提供我们设想的一些功能,具体详见:
Harald)今天的总结今天,回首往事,我们可以很自豪地说:“我们实现了我们所有的目标。”现在音视频交互变得越来越重要,许多产品和服务都支持Web和Native之间的无缝交换,而他们之中绝大部分都是基于我们现在开放出的标准API——这些API的底层实现基本上都是基于WebRTC
。一套通用标准促进了整个行业的发展,Firefox、Opera和微软都已经在支持WebRTC技术了。这已经导致超过20多亿浏览器用户使用了WebRTC技术,仅仅Chrome上每周就有超过10亿分钟的音视频通话,以及超过500T的数据传输(通过WebRTC的数据通道)。WebRTC从一开始就秉持一种很开放的态度,向视频编解码免版税方向迈进。在WebRTC中80%音频通信采用Opus,而最近推出的VP9比VP8节省70%的带宽。由于VP9的努力发展,媒体开放联盟在视频编解码免版税道路上又多了一种选择,以及增加了更多的合作空间。今天,WebRTC技术在音视频领域已经证明了自己的强大,在接下来的几年里,我们期望看到一个更加强大的WebRTC。接下来我们会持续改进音视频质量。我们在WebRTC中愿意采用一些通用的编解码来实现交互通讯,但有一些互操作的问题要去解决。另外作为未来编解码的VP9,他后面在压缩率方面会持续改进,以便更好支持低带宽下的通讯。今天的通信都发生在许多不同网络条件下,从EDGE到LTE。WebRTC面临多样化的网络条件,所以必须能够做出相应的调整。所以我们一直在努力改善拥塞控制算法和优化媒体传输配置来适应各种状况,这里面也有很多机会和方法来改善和简化媒体协议以适应当今网络需求。五年前,大多数通信发生在桌面上。但现在一切都变了,WebRTC技术已经发展到要满足各种移动通信应用的需求。展望未来,还有很多机会,如VR。WebRTC这个平台只会随着时间推移而价值愈加明显,现在仅仅是开始。我们要做的就是:努力做好WebRTC这个平台。(作者:Google
Harald)(原文链接:

摘要即时通讯云网易云集SDK新版发布,本次发布的版本号为:2.5.0。发布的版本本次发布的版本号为
2.5.0版,更新时间为:2016年7月08日。iOS 2.5.0 更新内容新增添加定期清理
SDK
日志的功能添加聊天室临时禁言的接口支持转发消息网络通话新增是否自动旋转远端画面的设置autoRotateRemoteVideo修正修复聊天室
Tip 消息无法正常解析的问题Android 2.5.0 更新内容新增1.
添加文本消息的全局搜索接口:MsgService#searchAllMessageHistory。2.
添加消息转发功能:MessageBuilder#createForwardMessage,支持除通知消息和音视频消息以外的消息类型。3.
添加聊天室临时禁言接口:ChatRoomService#markChatRoomTempMute,支持设置临时禁言时长。变更1.
将注册群通知消息过滤接口移动到 MsgService
中:MsgService#registerIMMessageFilter
,并支持单聊和群聊的通知类型消息过滤,不再限于群通知消息,同时支持音视频类型消息过滤。2.
聊天室架构调整,聊天室业务仅在 UI 进程处理。3. SDK
输出jar包按模块分离:nim-sdk.jar(必须)、nim-chatroom.jar(可选聊天室模块)、nim-rts.jar(可选实时会话白板模块)、nim-avchat.jar(可选实时音视频模块)、nrtc-sdk.jar(实时会话、实时音视频基础库),供开发者按需组合使用。Web
SDK 2.5.0
更新内容变更获取用户名片数组限制每次最多只能获取150个名片新增转发消息重发消息获取包含关键词的本地历史记录新增参数global表示是否全局搜索同步开关syncExtraTeamInfo,
控制是否同步额外的群信息, 默认true会同步额外的群信息,
目前包括当前登录用户是否开启某个群的消息提醒 (SDK 只是存储了此信息,
具体用此信息来做什么事情完全由开发者控制)调用接口修改自己的群属性来关闭/开启某个群的消息提醒调用接口是否需要群消息通知来查询是否需要群消息通知设置聊天室临时禁言Windows(PC)
SDK 2.5.0
更新内容修复语音播放停止延迟问题会话列表更新时消息未读数目错误的问题新增消息历史本地全局搜索,
nim_msglog.h群组增加获取群信息和成员信息的同步接口,
nim_team.h聊天室临时禁言, nim_chatroom.h消息转发接口,
nim_talk.h音视频支持SOCKS5代理对端视频画面自动旋转开关下载地址请从以下官网地址下载:

摘要即时通讯云服务商LeanCloud
2016年7月13日因由于突发硬件故障,导致雪崩致使即时通讯服务瘫痪48分钟之久!以下消息来自LeanCloud官方:7
月 13 日早上 9
点左右,我们内部在使用中国节点的应用控制台时遇到报错,于是很快便定位到某一集群由于突发硬件故障而引起存储服务中断,经过抢修问题得以解决。大约一小时后正当我们在继续对该集群进行加固处理时,突然遇到流量高峰,该集群的性能逐渐下降并再次发生了故障。此次故障影响到中国节点上
20%
的应用无法使用存储及其依赖服务,如实时通信、云引擎等。美国节点不受影响。故障时间及范围08:49

  • 09:08:存储服务内部某一集群发生硬件故障,导致 20%
    的应用的存储服务中断(约 19 分钟)。09:53 –
    10:22:该集群受到流量冲击后性能降低并再次瘫痪(约 29
    分钟)。前后共持续约 48
    分钟。事故过程08:49:应用控制台出现报错,立即进行排查。08:56:发现某个集群硬件故障,导致集群性能不断降低,响应过于缓慢,到几乎不可用。09:08:隔离故障机器,重启相关服务后,集群慢慢恢复了正常。09:53:有大量连接涌入,堵塞了存储系统的读写队列,使得该集群性能再次下降。09:58:该集群响应过于缓慢,几乎不可用。开始阻断连接,扩充集群并重启集群上的相关服务。10:22:集群服务逐步恢复,并重新开放连接。后续改进措施加强对集群硬件失败的监控和报警。提高自动化故障处理能力,降低系统
    downtime
    时间。尽快升级底层存储系统的存储引擎,减少读写队列拥塞的可能性,进一步提升服务性能。LeanCloud官方地址:

相关文章