ZMQ测试代码样例

ZMQ测试代码样例

背景

有部分网友提到上篇文章ZeroMQ性能分析,没有提供测试代码,想要自己验证测试结果;本篇文章,主要介绍代码层面,如何使用ZeroMQ。测试样例有python版本、C/C++版本。

生产-消费者模型

根据官方介绍,ZeroMQ是支持多语言,也就是说,它支持在多种不同语言的进程之间实现通讯。我们想要验证的场景是,生产者-消费者模型,一个生产者,多个消费者,ZeroMQ是否支持这种模型、数据共享性能如何,这也是常见的编程模型。

这个图的表达有一定的误差,例如生产者是进程,将任务队列替换成ZeroMQ,并且ZeroMQ内部也没有队列,图仅可用于示意。从尽快出验证结果的[……]

阅读全文

1 Star2 Stars3 Stars4 Stars5 Stars (1 人打了分, 平均分: 4.00 out of 5)
Loading...
IPC利器,ZMQ性能分析

IPC利器,ZMQ性能分析

背景

最近一段时间都在做方案设计,有一模块会使用开源组件,根据有关同事经验,开源组件在某些场景下会出现coredump,考虑到这种不稳定性因素、以及后续不同组件版本符号之间的冲突,要把影响降到最低。选择采用多进程方案来实现,就需要使用到IPC技术。

进程间通信方式

努力回想操作系统教材上进程间通讯方式的概念,常见的IPC方式包括,管道、消息队列、共享内存、本地socket,而业界比较知名的可用于进程间通信的组件有ZMQ,也得到同事们的一致推崇。而我们的场景下,进程间共享的数据最大为32MB

ZeroMQ介绍

ZeroMQ是一种基于消息队列的多线程底层网络[……]

阅读全文

1 Star2 Stars3 Stars4 Stars5 Stars (1 人打了分, 平均分: 5.00 out of 5)
Loading...
WebRTC中GCC 算法原理介绍与分析

WebRTC中GCC 算法原理介绍与分析

近期主要关注实时音视频的弱网优化技术,重点分析WebRTC的相关技术实现,主要包括抗拥塞、抗丢包,会通过一系列文章来分享我的学习所得,本次介绍拥塞控制算法GCC(Google Congestion Contrl) 原理与实现。

GCC 作为官方的拥塞控制算法,被广泛应用在实时音视频领域,包括腾讯会议、Agora、华为WeLink等VoIP音视频产品中。主要用来估计带宽,根据可用带宽控制当前的发送速度,减少传输链路发生拥塞的概率,尽可能降低传输链路带来的延时。

网络拥塞产生的原因,网络传输链路所承载的数据量超过了它所能处理的极限,传输延时增大,产生丢包、抖动。进而导致实时通讯中音视频[……]

阅读全文

1 Star2 Stars3 Stars4 Stars5 Stars (1 人打了分, 平均分: 5.00 out of 5)
Loading...
Markdown—工程师的写作神器

Markdown—工程师的写作神器

作为工程师日常除了写代码,也要写很多文档,例如 项目方案、接口文档、项目总结。我们都习惯了与代码打交道,在word上写文字,需要手动修改文字格式,缺乏写代码的畅快感。用MarkDown来写文档,既能享受写代码的乐趣,也能写出格式清晰的文章。

Markdown是一种标记语言,支持大多数html语法,纯文本,兼容性极强,不存在格式不兼容问题。可转换成HTML、PDF、WORD文档;标记语法可读性很强。

标题

只需要在文本前面加上 # 即可,根据#个数的不同,可以增加二级标题、三级标题、四级标题、五级标题和六级标题,总共六级,类似word里面的标题个数。同意设置比word里面逐个改[……]

阅读全文

1 Star2 Stars3 Stars4 Stars5 Stars (1 人打了分, 平均分: 5.00 out of 5)
Loading...
WebRTC 原生demo AppRTC弱网抗性分析

WebRTC 原生demo AppRTC弱网抗性分析

上篇文章介绍 WebTC 原生demo 在Android 平台下编译方法,本次对原生demo AppRTC 的音视频弱网抗性进行分析,音频测试采用POLQA设备测试不同网络环境下的MOS分变化;视频测试采用自研方法计算卡顿率。弱网条件包括,丢包、延时、带宽限制

丢包会导致语音卡顿,人耳主观感受就是吐字不清,这对于VoIP通话、在线会议都是不可接受,分析原生demo 在不同丢包率下的MOS分变化

  • 无丢包时,MOS分可以达到4.7分,几乎达到POLQA测试MOS的上限,音质非常好。
  • 丢包率在15%时,MOS分已经低于3.5分,音频卡顿较严重。基本就是丢包抗性上限。
  • 上下行丢包抗性相[……]

    阅读全文

1 Star2 Stars3 Stars4 Stars5 Stars (1 人打了分, 平均分: 5.00 out of 5)
Loading...
远程桌面卡顿,分析与思考

远程桌面卡顿,分析与思考

最近工作上频繁需要与异地同事交流,会使用到远程桌面,使用中发现视频画面非常卡,严重影响使用。画面卡顿直接原因是丢帧,间接原因是产生了丢包

我们双方都是在公司网络下使用,网络质量一切正常。经过测试验证,我与北京本地的同事使用远程协助没有问题,和杭州的同事使用就出现问题。直观感受是杭州同事这边的网络问题。杭州同事直接ping www.smiletoyou.cn ,ping结果正常,没有丢包、rtt也比较平稳。

直接查看IP,发现杭州同事的出口IP是xx 云,实际使用中除了三大运营商之外,这种xx云出口统一认为是小运营商。基于国内的网络环境,小运营商用户统一用小运营商服务器覆[……]

阅读全文

1 Star2 Stars3 Stars4 Stars5 Stars (1 人打了分, 平均分: 5.00 out of 5)
Loading...