一个关于Darwin Streaming Server 访问次数的缺陷

一个关于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类的说明。

 

通过以上改动，重新编译运行。通过压力测试一切正常。本人对Darwin Steaming Server还不是非常熟悉，不足之处请大家原谅。

 

 

 

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