14.live555mediaserver-setup请求与响应-创新互联
live555工程代码路径
live555工程在我的gitee下(doc下有思维导图、drawio图):https://gitee.com/lure_ai/live555/tree/master
学习demo
live555mediaserver.cpp
学习线索和姿势
1.学习的线索和姿势
网络编程
流媒体的地基是网络编程(socket编程)。
[网络编程学习]-0.学习路线。
绘图规则
本文的对象图和思维导图遵守的规则详见:
2.绘图规则
非阻塞服务端网络编程流程
socket创建、bind、listen、select、accept、select、recv/send-close。
rtsp协商流程
options、describe、setup、play、pause、teardown、get parameter、set parameter
本节内容和目标
(1)rtsp协议的setup请求与响应
(2)思维导图绘制
(3)wireshark抓包
(4)对象图
正式开始
DESCRIBE协商完事,VLC接着下发了setup信令,开始setup协商。
请求报文如下
图14-1
可以参照live555mediaserver-如何解析rtsp请求报文把这请求报文解析出来。需要注意的是解析的只局限于请求方法、CSeq、Session、Content-Length等,它下发的其他字段就过滤了。
需要关注的是,这里服务端会用来识别发送模式——UDP or TCP?——这个字段是Transport字段——如果是RTP/AVP/TCP,则要求采用TCP方式进行数据传输。如果是RTP/AVP那么就是UDP。还有其他下面详说。
根据前面知道,每一个客户端链接,在服务端都绑定一个对象RTSPServer::RTSPClientConnection,每次客户端协议来数据来了,都会调用到RTSPServer::RTSPClientConnection::handleRequestBytes里,如下图目前知道OPTIONS、DESCRIBE、REGISTER、DEREGISTER、特殊url的GET_PARAMETER和SET_PARAMETER是会在这个对象里处理。
图14-2
那么从setup开始,又新建一个处理对象进行处理了。怎么创建的呢?RTSPServer::RTSPClientConnection::handleRequestBytes识别到时setup信令,调用流程如下图14-3。
图14-3
图14-3所示,此时setup处理流程会走到红箭头1,GenericMediaServer::createNewClientSessionWithId,这个是对象DynamicRTSPServer的父类的父类的成员,它主要干2件事,一个是创建对象RTSPServer::RTSPClientSession,另一个是把这个对象加入到GenericMediaServer::fClientSessions这个成员管理的hash链表了,如下图,——后面想想,图是代码的映射,它们应该对应起来,先贴出来代码:
Session的产生
代码图中标记1中sesionId是随机产生的数字,然后和新对象绑定一起,在组响应包时会作为Session字段返回给VLC客户端的,play时vlc又会下发过来,用以找到正确的新对象的。
新对象的产生
代码图中,第2和第3标记执行完就是如下图的14-4和14-5的模样。
14-4
fClientSessions这个成员管理的hash链表如下图14-5。整个图太大,只能截断,可以看我gitee上live555工程doc下的对象图。
图14-5
如上图14-5,和describe一样是同样类型的hash链表,就直接拷贝过来了,只是链表成员不一样的——setup把新创建的对象RTSPServer::RTSPClientSession的父类的指针加入到这个链表里的value里了。注意代码图的标记3在add时把sesionid传给了这个链表成员的key值,后面play下发会再次通过这个sessionid进行查找到这个新对象。
接着调用新对象RTSPServer::RTSPClientSession的handleCmd_SETUP方法,
它又调用GenericMediaServer::lookupServerMediaSession,而它是个虚方法,实际调用的是DynamicRTSPServer::lookupServerMediaSession(原因参见上一节)。然后查找fServerMediaSessions管理的hash链表是否有这个url文件路径,因为describe已经插入了,在这里找到了,又移除它,又重新创建,具体原因,没有细看。
这个最后又调用RTSPServer::RTSPClientSession的回调静态方法SETUPLookupCompletionFunction1,接着调用新对象的handleCmd_SETUP_afterLookup1方法,然后最终来到了setup组响应报文的地方——handleCmd_SETUP_afterLookup2。其流程如下图14-6.
图14-6
如图14-6数字1是调用GenericMediaServer::lookupServerMediaSession的流向,太大了截图放不下,算了。数字2是又回调回来了。最终是数字4来到了handleCmd_SETUP_afterLookup2。
其主要干了啥事,如下思维导图,图14-7.
图14-7
创建对象数组 struct streamState 保存各个ServerMediaSubsession对象,这个保存的就是前面创建的ServerMediaSubsession对象。代码图如下:
代码图对应的对象图如下图14-8——代码图一执行就如下图模样。.
图14-8
模拟类就是示意,因为类图太大了,只能把那个离的远的类在这一张图中表示出来了。
接着是解析协商传输方式,如下图14-9。
图14-9
streamingMode这引用变量默认是RTP_UDP。while来解析RTP_TCP和RAW_UDP,而我们的VLC下发的setup信息如图14-1中是RTP/AVP/TCP,这里自然就是RTP_TCP了。
然后根据根据不同的传输方式组不同的setup响应报文。
图14-10
注意呀,里面除了传输方式,还有个字段非常关键——Session字段,这个就是前面看到的sessionid了,这个告诉VLC客户端,你等会play的时候下发的Session字段应该填什么,这样服务端才能找到新对象RTSPServer::RTSPClientSession。
到此整个setup响应流程完毕。setup的完整处理思维导图如下图14-11.
图14-11。
其组装的setup响应报文用wireshark抓包如下图14-12.。
图14-12
小结
为了实现setup业务,又新增了几个对象如下图14-13.
图14-13.
可以看到,除了模拟的2个类(类图太大了,为了在一张图展现出来就模拟了下就是示意的意思)不是本节新创建的——最左边是早创建了,最右边是describe就创建了,在setup又销毁重建了,就不算了——其他的新增了几个对象:
(1)RTSPServer::RTSPClientSession。SETUP、PLAY、PAUSE、TEARDOWN、正常url的GET_PARAMETER和SET_PARAMETER都在这个新对象里处理了。
(2)struct streamState对象数组。这个为何是数组呢?因为如果describe阶段sdp有2个m字段——假如一个音频一个视频,则VLC会下发2次setup,那也就会走2次setup流程,这个会怎么样呢?没有细看,应该会创建2个subsession吧,回头再说。
(3)一个hash链表。它这个呀主要是把setup新建立的对象RTSPServer::RTSPClientSession管理起来,和sessionid绑定,组sdp响应包。
在追踪setup业务线索的过程中,发现了live555为了实现这个业务新增了这几个对象(目前关注点),然后就把代码转化成图的形式。
你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧
新闻标题:14.live555mediaserver-setup请求与响应-创新互联
转载来于:http://azwzsj.com/article/eeege.html