Resiprocate协议栈分析Word文档格式.docx

1、在Resiprocate中一些RFC3261中定义元素的对应：建议：利用CRC卡片的方式去记录理解Resiprocate中的大量的类及其关系。CRC：类、职责、协作。部分设计的理解OBSERVER/VISITOR/COMMAND/ITERATOR模式，工厂模式（大量容器的使用也是一种变体如:DialogSet），代理类句柄类（界面实现分离，隐藏实现）,大量的界面类（如AppXXX系列）是遵循大师BS“界面和实现分离”的原则吧；而句柄方式对对象的间接管理是老外的惯用伎俩啦,关于句柄设计从大师BS的著作到的Handle_Body论和的大段描述再到都有发挥和外延，感兴趣可以观之。插播： 源码中的大量

2、Clone函数是模仿大师BS的虚拟构造函数一说,是原型模式的体现；源码中对同步的封装值得借鉴，其中有“资源开始即初始化”理论的体现；在DUM部分回调机制所遵循的著名“好莱坞原则”；句柄和代理的一个特点就是重载了operator-、operator*等;源码中也非常注重效率如Sip Core部分中大量Hash表的建立。 T* operator-（） return get（）; const T* operator-（） const T& operator- （） return *get（）; const T& operator*（） constHandled:Handled（HandleManag

3、er& ham） : mHam（ham）, mId（Handled:npos） mId = mHam.create（this）;IdHandleManager:create（Handled* handled） mHandleMap+mLastId = handled;/ typedef HashMap HandleMap; /HandleMap mHandleMap; return mLastId;1. SIP Stack分析11 Resiprocate SIP Stack系统架构图示12 FIFO流的走向图13 Sending datagram1. 4 Process Incoming UD

4、P2. Application/DUM设计浅析抽象接口：CLASS HANDLED ，CLASS InviteSessionHandler（诸如此类） 对象之源：CLASS HANDLED（多态和控制的基础）交互控制： CLASS Handle，CLASS HandleManager概念封装成类典型：CLASS Dialog, CLASS DialogId, CLASS DialogSet, CLASS DialogSetId, CLASS InviteSession.Utility工具类：CLASS BaseCreator , CLASS DestroyUsage, CLASS Profil

5、e流动之源：DialogUsageManager:process（），Dialog:dispatch（const SipMessage& msg）状态机的位置：incomingProcess，DialogSet:dispatch，Dialog:dispatch在整个Resiprocate大家族中事务层概念的体现是TransactionUser类，而其真正的实现和管理类就是DialogUsageManager；从其：class DialogUsageManager : public HandleManager, public TransactionUser能看出来；HandleManager点出

6、了DialogUsageManager的管理功能的本质，并且管理各种对象（Handle是各类对象的句柄）。在整个Resiprocate系统中不管是我们发出或者收到的SIP Message都是放进了先进先出的队列然后不断轮询处理，这有点象Windows的消息系统，对应收发的消息DUM提供事件通知的机制。DUM利用事件回调模型，事件响应可以选择继承系列XXXHandler抽象接口，并向TU注册，以实现VISITOR模式;我在另外的文档里也提到这是Reactor（Dispatcher,Notifier）模式，应用程序开发者只负责实现具体事件处理程序，并在反应器上注册它们 -“好莱坞原则”。Dialo

7、gUsageManager是sip事务层管理类，是一个大总管的角色；看其Makexxx系列的函数能明白它能发起一系列登陆、会话邀请的动作及其回复。Dum定义了很多句柄管理类，通过它我们能得到真实的对象，从而完成操作，这在事件响应中非常有用。在Dum（DialogUsageManager）的类中基本上这样一条线（以INVITE为例）：DialogUsageManager产生Dialog Set, Dialog Set产生Dialog, Dialog产生InviteSession; InviteSession又分Client InviteSession和Server InviteSession。而

8、上面的各个对象的PROCESS或者DISPATCH函数产生的各种状态的变化并触发相应事件。在DUM的IM/PRESENSE部分广泛使用SUBSCRIBE/NOTIFY的模式，目前协议的定义似乎参照成熟的设计模式。个人一直比较喜欢这段论述：session有两种含义，一种是传统意义上的RTP会话，一种是信令意义上的会话。SIP中的会话指后一种，在层次上它在dialog之上，也就是dialog可以看成session的组成单元。二者的分别主要基于目前出现的subscription应用，对于session和subscription可以共享一个dialog，dialog由基本的会话标识组成，如 Call-

9、ID,From-Tag,To-Tag，以及一些目的target等共性单元组成。而session除了具备这些单元外，包含INVITE建立起的会话其他内容，例如INVITE引起的状态机处理内容、PRACK处理记录等内容。有一个最为重要的区别是：Session是完成了SDP的Offer-Answer过程，也就是此时双方可以进行双向的RTP传输了。而Dialog只是双方建立了联系，这个联系是通过Dialog Context来记录的。在Dialog状态下双方不一定可以作双向的RTP传输。所以必定是Dialog在前，而Session在后，但两者可以同时一起建立。 Session是基于SDPMessage的

10、交互，没有SDP的交互，就没有Session。而Dialog是基于请求消息中的Header Field进行交互。因此两者在层次上也是不一样的。下图是DUM中各种对象实例间的关系表示：DUM中几个重要的类图： 3. RESIPROCATE SIP Core重要模块的简单介绍SipStack模块SipStack是Sip Stack Core的面向外界的接口；可以说它是Sip Stack Core的外覆类（wrapper）或者是界面类（以大师BS的观点来看），它是和外界交互的窗口和协议，具体的实现又分散到更具体的实现类和层次。在整个的协议栈架构中SipStack处于承上启下的位置，它既面向DUM层（

11、表现为向DialogUsageManager服务）又可以直接为外界（如UI）所用；列举其主要面向外界的接口函数：/* Adds a TU to the TU selection chain. Tus do not call receive or receiveAny, the SipStack will call postToTu on the appropriate Tu. Messages not associated with a registered TU go into SipStack:mTuFifo. */ void registerTransactionUser（Transac

12、tionUser&）;注释基本上已经讲的很清楚，我就补充其交互的细节吧。这个函数基本上能让我们看到TU和SipStack交互间其visitor/observer模式的影子。void SipStack:registerTransactionUser（TransactionUser& tu） mTuSelector.registerTransactionUser（tu）;回溯SipStack的成员变量：/ Responsible for routing messages to the correct TU based on installed rules TuSelector mTuSelecto

13、r;把SipStack中的Transaction User角色独立出来交与一个独立的类管理是个不错的选择。消息的流向分向两端，一路向下直达Transport层而去，一路向上提交Transaction User直至UI。因此接口类Message中存在这个函数就不足为奇啦：class Message 。 void setTransactionUser（TransactionUser* t） tu = t; TransactionUser* getTransactionUser（） return tu; TransactionUser* tu;正是setTransactionUser给予消息Tran

14、saction User归属。而在TransactionState中我们将会看到SipMessage是如何兵分两路的：static void sendToTU（TransactionUser* tu, TransactionController& controller, TransactionMessage* msg）;void sendToWire（TransactionMessage* msg, bool retransmit=false）;现在我们先重点关注一下sendToTU：voidTransactionState:sendToTU（TransactionUser* tu, Tran

15、sactionController& controller, TransactionMessage* msg） msg-setTransactionUser（tu）; controller.mTuSelector.add（msg, TimeLimitFifoInternalElement）;上面探索了一下SipStack和TU层的交互都要跑远啦，让我们再回到SipStack看看这个界面类其他的迎来送往的窗口吧。一、发送消息的两个重载函数： Interface for the TU to send a message. Makes a copy of the SipMessage. Caller

16、 is responsible for deleting the memory and may do so as soon as it returns. Loose Routing processing as per RFC3261 must be done before calling send by the TU. See Helper:processStrictRoute param msg SipMessage to send. param tu TransactionUser to send from. void send（const SipMessage& msg, Transac

17、tionUser* tu=0）; void send（std:auto_ptr msg, TransactionUser* tu = 0）;再看了一下这两个函数体的实现比较简单，还是端上来吧：send（const SipMessage& msg, TransactionUser* tu） SipMessage* toSend = new SipMessage（msg）; if （tu） toSend- setFromTU（）; mTransactionController.send（toSend）; checkAsyncProcessHandler（）; mTransactionControl

18、ler.send（toSend）这一段才是我们值得关注的地方，很显然这是消息的去向，现在我们不用管它去向哪儿，我们知道它被转交给mTransactionController去具体完成任务，就象在一条生产线上我们把消息交给了下游或者另一个直管部门去处理。SipMessage是我们投递出的邮件，从投向邮筒的那一瞬间，开始了它向各个驿站的传递；出于职责链上的各个类和对象是任务传递驿站的抽象和实现，是代码所表现出的和谐世界，当然如果是垃圾代码的话，那就是一个混乱的世界和杂物堆放的仓库。checkAsyncProcessHandler（）这是协议栈提供的异步消息处理的一种推荐方式，协议栈源码中只是实现了

19、个大概，具体的异步处理细节需要根据具体情况而完成其实现类，此处再次体现了“封装变化的概念”的要诀。因为异步处理句柄是指向抽象基类的指针：AsyncProcessHandler* mAsyncProcessHandler;二、SendTo有好几个重载函数，看看注释再和Send比较一下就可耶。/* this is only if you want to send to a destination not in the route. You probably dont want to use it. */ void sendTo（std: msg, const Uri& uri, Transacti

20、onUser* tu=0）; msg, const Tuple& tuple, TransactionUser* tu=0）; void sendTo（const SipMessage& tuple, TransactionUser* tu=0）;三、就如在Win32编程中有SendMessage和PostMessage一样，SipStack消息分发中也有一个Post。 /* Makes the message available to the TU at some later time - specified in seconds. Note: TranasactionUser subcla

21、sses can just post to themselves. param message ApplicationMessage to post param secondsLater Number of seconds before message is to be posted. param tu TransactionUser to post to. void post（const std:ApplicationMessage message, unsigned int secondsLater, void postMS（const std: unsigned int ms, void

22、 post（const ApplicationMessage& message）; message, unsigned int secondsLater, milli-seconds. Makes a copy of the ApplicationMessage. Caller is responsible for deleting the memory and may do so as soon as it returns. TransactionUser subclasses can just post to themselves. param ms Number of milli-sec

23、onds before message is to be posted. void postMS（const ApplicationMessage& message, unsigned int ms,ApplicationMesage基本上是个结点类，因此可以自定义自己的消息类，然后自己管理；因为我们可以看到Post出去的消息更多的是交给TU去处理，TU层就在应用层隔壁。四、下面的函数，非常容易看明白。 /* Retrieve a SipMessage off the old TuFifo. Caller now owns the memory. Returns 0 if nothing th

24、ere. Since the addition of TransactionUsers, this method is deprecated. This only looks into the old TuFifo that is not associated with any TransactionUser. Applications posting non-sip messages must use receive any. If non SipMessages are on the Fifo, then they are just deleted. deprecated returns

25、pointer to received SipMessage, 0 if nothing there. SipMessage* receive（）; Retrieve a Message off the old TuFifo. Caller now owns the memory. Returns returns pointer to received Message, 0 if nothing there. May return TransactionTerminated*, TimerMessage*, SipMessage* or derived ApplicationMessage* Message* receiveAny