EasyDarwin

面向企业级的流媒体平台框架

EasyDarwin开始于2013年,遵循 Apple开源License APSL,为了敏捷流媒体服务器开发和简化企业流媒体应用开发而诞生的。

详细 >>

[征文]一个关于Darwin Streaming Server 访问次数的缺陷


先给大家简单介绍一下这个问题的背景,在实际的应用中遇到这样一件事,客户端使用RTSP请求访问服务端的视频信息,服务端使用的是Darwin Streaming Server。每天早上重启一下...

先给大家简单介绍一下这个问题的背景,在实际的应用中遇到这样一件事,客户端使用RTSP请求访问服务端的视频信息,服务端使用的是Darwin Streaming Server。每天早上重启一下服务,白天可以正常运行,但是过了一个晚上,第二天早上过来看,程序就不正常了。进一步了解到,有客户端在晚上的时候会通过轮询方式访问视频信息。系统环境为客户端使用的Window 7,服务端使用的是Windows2008 server。

为了解决这个问题,费了好些功夫,大概花了一周左右的时间进行调试。最终发现了一个关于Darwin Streaming Server访问次数的缺陷。

下面讲一下调试过程。

首先,我默认认为应该不是转发的问题,所以就从客户端上下功夫。客户端原本连接方式是每次请求为一个短链接。实际运行效果很快就会发生上述问题,后来改成每一个RTSP 会话为一个长连接,这样效果比之前好一些,但是依然会出现失败的情况,感觉找不到头绪。

然后,我想到是不是网络问题引起的,因为经常晚上打开程序,早上就会有报错现象。为了排查这个问题我将服务端和客户端放到了一台机器上进行测试。依然有问题,排除网络原因。

既然不是网络原因,还是从程序入手。写测试程序快速发送请求包。果然在大约7000次左右就会出现访问失败的情况。每次都很有规律。既然能快速重现,我想应该就比较好解决了。

我将该现象在多个技术群里发了一遍,求助大家。大家反映没有遇到过,无解。还是自己来吧。先调客户端程序,Darwin的调试实在比较复杂,通过抓包测试发现客户端发送消息都成功了,在服务端也收到了客户端发送请求包,但是服务端程序没有反应。难道是发送的消息有问题,Darwin对客户端发送的端口号作了限制?死马当作活马医吧,我在客户端试着绑定客户端发送端口,再次测试。等待结果... ... 结果出来了。现象依旧。因为客户端是用ACE框架写的,是不是ACE本身隐藏的缺陷?我将这个疑问,发送群里。别人建议我还是不要用ACE,ACE确认可能存在一些缺陷。在没有别的想法的时候,我决定先修改客户端。改成使用Windows底层Socket的方法来发送消息。再次期待... ...再次失望。

我终于推翻自己最初的想法。决定应该在服务端找办法。单步跟踪调试Darwin, 发现连接事件和发送包消息的事件,Darwin都能捕获到。但是不知道为什么就不能进入RTSPSession的Run。于是再次查找Darwin相关资料。了解其核心消息机制。在此期间边看边调试。

通过跟踪调试,找到这样一个消息机制。

Socket的读取都在EventContext类中的EventThread线程中,具体到EventThread::Entry()中的select_waitevent()捕获。

下面看一下这个函数。

捕获到Socket的事件后,会在EventThread::Entry()函数中查找EventThread::fRefTable,获取对应的EventContext。如果是RTSP请求消息,那么,得到的是EventContext类型的派生类RTSPListenerSocket。在对应的ProcessEvent()中accept Socket,每一个RTSP线程会创建一个。

下面我们接着看ProcessEvent()这个函数。根据派生关系,应该会进入下面的函数。void TCPListenerSocket::ProcessEvent(int /*eventBits*/)。

经过多次调试,发现问题就出现在theSocket->RequestEvent(EV_RE);这个函数中,我们先看一个这个函数做了什么?

这个函数要将RTSPSocket对应加入EventThread::fRefTable中,每次请求会先申请一个UID,申请方式是通过compare_and_store(8192 , WM_USER, &sUniqueID)生成的,然后会将这个UID和与RTSPSocket绑定,并加入到映射表中,而UID实际作用是通过窗口接收消息的唯一ID。这样在收到客户端发送的RTSP请求时,先在EventThread::Entry()捕获到消息,然后根据UID在fRefTable中查找对应的Socket对象。所以消息的类型实际上是依赖于UID这个值的。但是我们看上面那段代码,在生成UID的时候使用方法是循环获取ID的方式。具体可以查看compare_and_store代码?当请求次数足够多的时候,会发现UID有从头开始。这样由于之前的部分UID肯定会被占用掉,已经和其它Socket对应绑定了。所以通过新生成的UID在fRefTable表中获取的Socket对应必然是不对的。为了解决这个问题。我们需要先判断一下这个UID是否被占用,如果被占用了就不能再使用。

具体改动如下,在EventContext::RequestEvent(int theMask)的函数中增加判断UID是否被占用的逻辑。具体判断方式还是使用到了fRefTable这个参数的特性,不清楚的可以仔细阅读一下OSRefTable类的说明。

火烧云 2015年2月2日于北京



------------------------------ 分割线 ------------------------------
本站文章除注明转载外,均为本站原创或编辑,欢迎大家转载,但请务必注明出处,尊重他人成果,谢谢。
转载请注明:EasyDarwin;非本站文章均来自互联网,转载目的在于传递更多信息,并不代表本站赞同其观点和对其真实性负责。
文章中如果有错误可联系:johnson@easydarwin.org
推荐文章
安防和移动互联网行业比较火热的移动端手机......>
有人问到像美拍、秒拍这些短视频拍摄是怎么......>
最近更新
Easydarwin中大量使用gettimeofday来获取系......>
最近很多EasyDarwin爱好者提出了手机移动端......>
第一个到达的音频RTP包就将作为音频的关键帧......>
打开手机直播立即就能显示出主播视频,其实就......>
h264的功能分为两层,视频编码层(VCL)和网......>
友情链接 | 申请链接
EasyDarwin官方微信!