首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

模拟测试

今天,帮客户调试一个FreeSWITCH媒体问题,需要模拟测试一下。 首先,FreeSWITCH在公网上,客户端在NAT环境中。我们先用客户端呼叫9196。呼通后可以听到自己的回音。...FreeSWITCH解决这类NAT问题的办法就是等待客户端给它发送RTP。收到后便能“学习”到客户端的外网IP地址和端口号。...Auto Changing port from 192.168.7.6:50432 to 112.238.196.224:50432 好了,知道了客户端的IP和端口以后,我们就可以用iptables模拟包了...表示,所有发往IP 112.238.196.224和端口50432的,8%的直接丢掉不发。 上面的例子是模拟FreeSWITCH发送时。...在实际使用中,有时也会模拟FreeSWITCH接收端,可以用类似如下的命令来实现: iptables -A INPUT -p udp —src 112.238.196.224 —sport 50432

2.5K21
您找到你想要的搜索结果了吗?
是的
没有找到

微信为啥“离线消息”?

需求缘起 当发送方用户A发送消息给接收方用户B时,如果用户B在线,之前的文章《微信为啥“在线消息”?》聊过,可以通过应用层的确认,发送方的超时重传,接收方的去重保证业务层面消息的不重。...问题:用户B一次性拉取所有好友发给ta的离线消息,消息量很大时,一个请求很大,速度慢,容易卡顿怎么办? ? 回答:分页拉取,根据业务需求,先拉取最新(或者最旧)的一页消息,再按需一页页拉取。...问题:如何保证可达性,上述步骤第三步执行完毕之后,第四个步骤离线消息返回给客户端过程中,服务器挂点,路由器消息,或者客户端crash了,那离线消息岂不是丢了么(数据库已删除,用户还没收到)?...SMC理论:系统层面无法做到消息不重,业务层面可以做到,对用户无感知。 ? 问题:假设有N页离线消息,现在每个离线消息需要一个ACK,那么岂不是客户端与服务器的交互次数又加倍了?...再在客户端本地进行发送方分析,相比按照发送方一个个进行消息拉取,能大大减少服务器交互次数 (2)分页拉取,先拉取计数再按需拉取,是无线端的常见优化 (3)应用层的ACK,应用层的去重,才能保证离线消息的不重

2.5K60

Kafka “消息” ISR 机制解析

许多消息都会各种保证自己的产品不会消息或者消息丢失概率较小,但是靠谱的很少,而且消息队列消息排查起来是非常麻烦的,所以大多数在使用的过程中都会在上层或者下层建立一种消息核对或者应对丢失的策略。...在消息这方面,Kafka 算是有着不小的优势,只要去正确使用,Kafka 基本是不会产生丢失的,并且能做到精确一次处理。...Kafka 交付语义、producer中都提到了消息提交给broker中,基本就不会消息了,而这个消息主要是依赖于broker 中的ISR机制。...按照常识,要想保证高可用保证丢失,最直观的就是制造冗余,多做备份,数据互备嘛,Kafka 也是这么去做的。...ISR (in-sync replica)也就是这组与leader保持同步的replica集合,我们要保证消息,首先要保证ISR的存活(至少有一个备份存活),并且消息提交成功。

5.4K40

微信为什么消息?

1)client-A向im-server发送一个消息请求,即msg:R 2)im-server在成功处理后,回复client-A一个消息响应,即msg:A 3)如果此时client-B在线,则im-server...在若干场景下,可能出现msg:N丢失,且发送方client-A完全不知道,例如: 1)服务器崩溃,msg:N未发出 2)网络抖动,msg:N包被网络设备丢弃 3)client-B崩溃,msg:N未接收...4)client-B向im-server发送一个ack请求,即ack:R 5)im-server在成功处理后,回复client-B一个ack响应,即ack:A 6)则im-server主动向client-A...架构设计基本准则) 2)如果client-B不在线,im-server保存了离线消息后,要伪造ack:N发送给client-A 十、总结 1)im系统是通过超时、重传、确认、去重的机制来保证消息的可靠投递,不重...2)一个“你好”的发送,包含上半场msg:R/A/N与下半场ack:R/A/N的6个报文 3)im系统难以做到系统层面的不重,只能做到业务层面的不重 末了,微信的消息是不是这么发送的,偶不太清楚

3.5K91

HCIE数通排错思路。

HCIE面试中有一道项目题,网络中发生行为的排查思路和具体实施方法: 回答总体思路: 1、 先确定是否发生以及哪些设备访问的时候会发生; 当发现设备访问某一网段时有,可以先在多台设备上去...ping 目的网段的周围的多个网段(类似于诊断六那样),用于确定是何种流量还是所有流量都会; 如果是具体一种流量的话可以确定为做了路由策略或者策略路由(类似诊断六,带源不能通,不带源就行)...; 如果是多种流量都,造成的原因就可能很多,物理层、数据链路层、网络层以及策略路由都有可能; 2、判断位置; 方法有两种: 第一种:使用 ping 和 tracert 一段一段测试,先 ping...网关,然后是网关的下一跳,一直到目的地址,或者用 tracert 跟踪可以确定具体在哪一跳;这种方法简单,但较为粗糙一些,因为可能是间歇性的,需要多次ping 和tracert,测试多次。...(1)如果发生在物理线路上,接下来主要检测设备之间的物理链路;物理链路故障的原因主要有: ※双工或速率匹配 ※线缆接头接触不良或松脱 ※物理连线过长或出现破损 针对物理链路故障,具体排查方法如下

2.8K42

WebRTC重传大解密

目录 概述 NACK 问题一、数据真丢了,会一直重传吗? 问题二、重传次数不到最大限制次数,就会一直等待吗? 问题三、当大量时,会全部重传吗?...NACK 说到重传就不得不提到NACK技术,那么NACK是什么呢。...NACK技术作为WebRTC对抗弱网的核心技术之一,有两种发送模式,一种是基于序列号的发送,一种是基于时间序列的发送。对于一个因为连续而被判为丢失后,接收端会主动请求重传这个数据。...问题三、当大量时,会全部重传吗? 答案是否定的。因为WebRTC不仅限制了重传的次数,而且还限制了重传的个数。WebRTC每次要求重传的个数默认是1000个。...当然不是,只要最大个数超过1000个,就可以按照kProcessIntervalMs时间间隔请求一次重传。即使,只丢失了一个也会在规定的时间进行重传请求。

3.4K20

MySQL是如何保证数据的(一)

数据的一致性和完整性对于在线业务的重要性不言而喻,如何保证数据呢?今天我们就探讨下关于数据的完整性和强一致性,MySQL做了哪些改进。 1....Statement:基于操作的SQL语句记录到binlog中,建议使用。 Row:基于行的变更情况记录,会记录行更改前后的内容,row模式也是数据库数据的重要保证,推荐使用。...innodb_flush_log_at_trx_commit和sync_binlog都设置为1是MySQL数据中经典的双一模式,是数据库数据的保障。...MySQL的二阶段提交就保证了数据库在异常宕机重启后的数据丢失。 2....MySQL在集群架构中又做了哪些优化来保证数据丢失呢?我们下一章再来和大家分享MySQL在集群架构中的优化改进。

2.5K30

交换机问题定位

诊断工具 display工具 二层转发故障 定位思路 定位步骤 三层单播转发故障 定位思路 定位步骤 诊断工具 display命令行 ? 二层转发故障 定位思路 ?...第一步:判定设备 1.根据流量转发路径,在流量的入接口和出接口分别配置流量统计。 ? 2.查看入接口和出接口的流量统计,以确认是否在本设备产生。...如果出接口流量统计值与入接口流量统计值相等,则说明非本设备;如果出接口流量统计值小于入接口流量统计值,则本设备。 ?...三层单播转发故障 定位思路 ? 第一步:确认点 确认是否交换机产生,依然采用流量统计的方法,参见“二层转发”流量统计相关部分,此处不再赘述。...第三步:检查端口和链路 第四步:检查出端口是否存在拥塞 第三步、第四步与“二层转发”相关部分一致,此处不再赘述。

4.1K20

记一次分析

笔者当场就吃惊了,明明局域网内通信,为何视频有10%的。 ?...然后笔者首先验证的是第四种,应用内。这里先说一下笔者的测试场景: 192.168.0.103是FreeSWITCH的ip。192.168.0.102是软电话的ip。...很明显,FreeSWITCH已经将发出了,但是抓中却没有。可以排除应用内包了。 分析到这里,貌似只有“UDP buffer size不足”这个原因比较可疑了。...分析到这里,笔者开始怀疑,是不是通话根本没有,但是tcpdump由于自己的原因没有抓到,因此“显示的”。 不知道大家在抓结束后,有没有观察过tcpdump的输出。反正笔者是从来没有注意过。...经过测试,wireshark确实没有“”了。 ? ? tcpdump默认的buffer大小为2MB,这对于抓取视频来说远远不够,因此,加上-B很有必要。

3.2K30
领券