程序博客网 > 数据库建设方案

live555学习笔记13－RTPInterface详解

来源：互联网 发布：数据库建设方案 编辑：程序博客网 时间：2024/06/06 04:54
十三：RTPInterface详解


好几天没写blog了。看源码真累啊，还要把理解的写到纸上，还要组织混乱的思想，令人头痛，所以这需要激情。不过，今天激情又来了。


大家应该已理解了GroupSocket这个类。理论上讲那些需要操作udp socket 的类应保存GroupSocket的实例。但事实并不是这样，可以看一下RTPSink，RTPSource，RTCPInstance等，它们都没有保存GroupSocket型的变量。那它们通过哪个类进行socket操作呢？是RTPInterface！！
这些类接收的GroupSocket指针最后都传给了 RTPInterface 。为什么用RTPInterface而不直接用GroupSocket呢？这里面有个故事...扯远了。


要解答这个问题，让我们先提出问题吧。
首先请问，Live555即支持rtp over udp，又支持rtp over tcp。那么在rtp over tcp情况下，用 GroupSocket 怎么实现呢？GroupSocket可是仅仅代表UDP啊！
那么RTPInterface既然用于网络读写，它就应该既支持tcp收发，也支持udp收发。而且它还要像GroupSocket那样支持一对多。因为服务端是一对多个客户端哦。我们看一下RTPInterface的成员：
Groupsock* fGS;
tcpStreamRecord* fTCPStreams; // optional, for RTP-over-TCP streaming/receiving
嘿嘿，这两个紧靠着，说明它们关系不一般啊（难道他们有一腿？）。fGS－－代表了一个udp socket和它对应的多个目的端，fTCPStreams--代表了多个TCP socket，当然这些socket都是从一个socket accept()出来的客户端socket（tcpStreamRecord是一个链表哦）。
看到这个架式，我想大家都要得出结论了：RTPInterface还真是男女通吃啊！不论你客户端与我建立的是tcp连接，还是udp连接，我RTPInterface一律能接收你们的数据，并向你们发出数据！

证据一：向所有客户端发出数据：

[cpp] view plaincopyprint?
  1. Boolean RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize)  
  2. {  
  3.     Boolean success = True; // we'll return False instead if any of the sends fail  
  4.   
  5.     // Normal case: Send as a UDP packet:  
  6.     if (!fGS->output(envir(), fGS->ttl(), packet, packetSize))  
  7.         success = False;  
  8.   
  9.     // Also, send over each of our TCP sockets:  
  10.     for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;  
  11.             streams = streams->fNext) {  
  12.         if (!sendRTPOverTCP(packet, packetSize, streams->fStreamSocketNum,  
  13.                 streams->fStreamChannelId)) {  
  14.             success = False;  
  15.         }  
  16.     }  
  17.   
  18.     return success;  
  19. }  
很明显啊，先发送udp数据，一对多的问题在GroupSocket中解决。再发送tcp数据，一对多的问题本地解决。
证据二：从所有客户端读取数据：
我现在找不到直接的证据，所以我就憶想一下吧：当udp端口或tcp端口收到数据时，分析后，是哪个客户端的数据就发给对应这个客户端的RTPSink或RTCPInstance。
好像已经把最开始的问题解答完了。下面让我们来分析一下RTPInterface吧。

[cpp] view plaincopyprint?
  1. void RTPInterface::setStreamSocket(int sockNum, unsigned char streamChannelId)  
  2. {  
  3.     fGS->removeAllDestinations();  
  4.     addStreamSocket(sockNum, streamChannelId);  
  5. }  
  6.   
  7. void RTPInterface::addStreamSocket(int sockNum, unsigned char streamChannelId)  
  8. {  
  9.     if (sockNum < 0)  
  10.         return;  
  11.   
  12.     for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;  
  13.             streams = streams->fNext) {  
  14.         if (streams->fStreamSocketNum == sockNum  
  15.                 && streams->fStreamChannelId == streamChannelId) {  
  16.             return; // we already have it  
  17.         }  
  18.     }  
  19.   
  20.     fTCPStreams = new tcpStreamRecord(sockNum, streamChannelId, fTCPStreams);  
  21. }  
setStreamSocket()没必要说了吧，看一下addStreamSocke()。从字面意思应能了解，添加一个流式Socket，也就是添加tcp 
socket了。循环中查找是否已经存在了，最后如果不存在，就创建之，在tcpStreamRecord的构造函数中己经把自己加入了链表。对于参数，sockNum很易理解，就是socket()返回的那个SOCKET型
数据呗，streamChannelId是什么呢？我们不防再猜测一下（很奇怪，我每次都能猜对，嘿嘿...）：rtp over tcp时，这个tcp连接是直接利用了RTSP所用的那个tcp连接，如果同时有很多rtp 
session，再加上rtsp session，大家都用这一个socket通信，怎么区分你的还是我的?我想这个channel 
id就是用于解决这个问题。给每个session分配一个唯一的id，在发送自己的包时为包再加上个头部，头部中需要有session的标记－－也就是这个channel id，包的长度等等字段。这样大家就可以穿一条裤子了，术语叫多路复用，但要注意只有tcp才进行多路复用，udp是不用的，因为udp是一个session对应一个socket（加上RTCP是两个）。
想像一下，服务端要从这个tcp socket读写数据，必须把一个handler加入TaskScheduler中，这个handler在可读数据时进行读，在可写数据时进行写。在读数据时，对读出的数据进行分析，取得数据包的长度，以及其channel id，跟据channel id找到相应的处handler和对象，交给它们去处理自己的数据。
试想两个建立在tcp上的rtp session，这个两个tcp socket既担负着rtsp通讯，又担负着rtp通讯。如果这两个rtp session共用一个stream，那么最终负责这两个session通信的就只有一个RTPInterface，那么这个RTPInterface中的fTCPStreams这个链表中就会有两项，分别对应这两个session。tcpStreamRecord主要用于socket number与channel id的对应。这些tcpStreamRecord是通过addStreamSocket()添加的。处理数据的handler是通过startNetworkReading（）添加的，看一下下：

[cpp] view plaincopyprint?
  1. void RTPInterface::startNetworkReading(TaskScheduler::BackgroundHandlerProc* handlerProc)  
  2. {  
  3.     // Normal case: Arrange to read UDP packets:  
  4.     envir().taskScheduler().turnOnBackgroundReadHandling(fGS->socketNum(),handlerProc,  
  5.         fOwner);  
  6.   
  7.     // Also, receive RTP over TCP, on each of our TCP connections:  
  8.     fReadHandlerProc = handlerProc;  
  9.     for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;  
  10.             streams = streams->fNext) {  
  11.         // Get a socket descriptor for "streams->fStreamSocketNum":  
  12.         SocketDescriptor* socketDescriptor = lookupSocketDescriptor(envir(),  
  13.                 streams->fStreamSocketNum);  
  14.   
  15.         // Tell it about our subChannel:  
  16.         socketDescriptor->registerRTPInterface(streams->fStreamChannelId, this);  
  17.     }  
  18. }  
用UDP时很简单，直接把处理函数做为handler加入taskScheduler即可。而TCP时，需向所有的session的socket都注册自己。可以想像，socketDescriptor代表一个tcp socket，并且它有一个链表之类的东西，其中保存了所有的对这个socket感兴趣的RTPInterface，同时也记录了RTPInterface对应的channal id。只有向socketDescriptor注册了自己，socketDescriptor在读取数据时，才能跟据分析出的channel id找到对应的RTPInterface，才能调用RTPInterface中的数据处理handler，当然，这个函数也不是RTPInteface自己的，而是从startNetworkReading()这个函数接收到的调用者的。
上述主要讲的是一个RTPInterface对应多个客户端tcp socket的情形。现在又发现一个问题：SocketDescriptor为什么需要对应多个RTPInterface呢？上面已经讲了，是为了多路复用，因为这个socket即负担rtsp通信又负担rtp通信还负担RTCP通信。SocketDescriptor记录多路复用数据（也就是RTPInterface与channel id）用了一个Hash table：HashTable* fSubChannelHashTable。SocketDescriptor读数据使用函数：static void tcpReadHandler(SocketDescriptor*, int mask)。证据如下：

[cpp] view plaincopyprint?
  1. void SocketDescriptor::registerRTPInterface(  
  2. unsigned char streamChannelId,  
  3.         RTPInterface* rtpInterface)  
  4. {  
  5.     Boolean isFirstRegistration = fSubChannelHashTable->IsEmpty();  
  6.     fSubChannelHashTable->Add((char const*) (long) streamChannelId,  
  7.             rtpInterface);  
  8.   
  9.     if (isFirstRegistration) {  
  10.         // Arrange to handle reads on this TCP socket:  
  11.         TaskScheduler::BackgroundHandlerProc* handler =   
  12.             (TaskScheduler::BackgroundHandlerProc*) &tcpReadHandler;  
  13.         fEnv.taskScheduler().turnOnBackgroundReadHandling(fOurSocketNum,  
  14.                 handler, this);  
  15.     }  
  16. }  
可见在注册第一个多路复用对象时启动reand handler。看一下函数主体：

[cpp] view plaincopyprint?
  1. void SocketDescriptor::tcpReadHandler1(int mask)  
  2. {  
  3.     // We expect the following data over the TCP channel:  
  4.     //   optional RTSP command or response bytes (before the first '$' character)  
  5.     //   a '$' character  
  6.     //   a 1-byte channel id  
  7.     //   a 2-byte packet size (in network byte order)  
  8.     //   the packet data.  
  9.     // However, because the socket is being read asynchronously, this data might arrive in pieces.  
  10.   
  11.     u_int8_t c;  
  12.     struct sockaddr_in fromAddress;  
  13.     if (fTCPReadingState != AWAITING_PACKET_DATA) {  
  14.         int result = readSocket(fEnv, fOurSocketNum, &c, 1, fromAddress);  
  15.         if (result != 1) { // error reading TCP socket, or no more data available  
  16.             if (result < 0) { // error  
  17.                 fEnv.taskScheduler().turnOffBackgroundReadHandling(  
  18.                         fOurSocketNum); // stops further calls to us  
  19.             }  
  20.             return;  
  21.         }  
  22.     }  
  23.   
  24.     switch (fTCPReadingState) {  
  25.     case AWAITING_DOLLAR: {  
  26.         if (c == '$') {  
  27.             fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;  
  28.         } else {  
  29.             // This character is part of a RTSP request or command, which is handled separately:  
  30.             if (fServerRequestAlternativeByteHandler != NULL) {  
  31.                 (*fServerRequestAlternativeByteHandler)(  
  32.                         fServerRequestAlternativeByteHandlerClientData, c);  
  33.             }  
  34.         }  
  35.         break;  
  36.     }  
  37.     case AWAITING_STREAM_CHANNEL_ID: {  
  38.         // The byte that we read is the stream channel id.  
  39.         if (lookupRTPInterface(c) != NULL) { // sanity check  
  40.             fStreamChannelId = c;  
  41.             fTCPReadingState = AWAITING_SIZE1;  
  42.         } else {  
  43.             // This wasn't a stream channel id that we expected.  We're (somehow) in a strange state.  Try to recover:  
  44.             fTCPReadingState = AWAITING_DOLLAR;  
  45.         }  
  46.         break;  
  47.     }  
  48.     case AWAITING_SIZE1: {  
  49.         // The byte that we read is the first (high) byte of the 16-bit RTP or RTCP packet 'size'.  
  50.         fSizeByte1 = c;  
  51.         fTCPReadingState = AWAITING_SIZE2;  
  52.         break;  
  53.     }  
  54.     case AWAITING_SIZE2: {  
  55.         // The byte that we read is the second (low) byte of the 16-bit RTP or RTCP packet 'size'.  
  56.         unsigned short size = (fSizeByte1 << 8) | c;  
  57.   
  58.         // Record the information about the packet data that will be read next:  
  59.         RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);  
  60.         if (rtpInterface != NULL) {  
  61.             rtpInterface->fNextTCPReadSize = size;  
  62.             rtpInterface->fNextTCPReadStreamSocketNum = fOurSocketNum;  
  63.             rtpInterface->fNextTCPReadStreamChannelId = fStreamChannelId;  
  64.         }  
  65.         fTCPReadingState = AWAITING_PACKET_DATA;  
  66.         break;  
  67.     }  
  68.     case AWAITING_PACKET_DATA: {  
  69.         // Call the appropriate read handler to get the packet data from the TCP stream:  
  70.         RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);  
  71.         if (rtpInterface != NULL) {  
  72.             if (rtpInterface->fNextTCPReadSize == 0) {  
  73.                 // We've already read all the data for this packet.  
  74.                 fTCPReadingState = AWAITING_DOLLAR;  
  75.                 break;  
  76.             }  
  77.             if (rtpInterface->fReadHandlerProc != NULL) {  
  78.                 rtpInterface->fReadHandlerProc(rtpInterface->fOwner, mask);  
  79.             }  
  80.         }  
  81.         return;  
  82.     }  
  83.     }  
  84. }  
最开始的注释中解释了多路复用头的格式。这一段引起了我的兴趣：

[cpp] view plaincopyprint?
  1. case AWAITING_DOLLAR: {  
  2.         if (c == $) {  
  3.             fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;  
  4.         } else {  
  5.             // This character is part of a RTSP request or command, which is handled separately:  
  6.             if (fServerRequestAlternativeByteHandler != NULL) {  
  7.                 (*fServerRequestAlternativeByteHandler)(  
  8.                         fServerRequestAlternativeByteHandlerClientData, c);  
  9.             }  
  10.         }  
  11.         break;  
  12.     }  
啊！原来ServerRequestAlternativeByteHandler是用于处理RTSP数据的。也就是从这个socket收到RTSP数据时，调用ServerRequestAlternativeByteHandler。如果收到RTP/RTCP数据时，先查看其channel id，跟据id找到RTPInterface(RTCP也是用了RTPIterface进行通信)，设置RTPInterface中与读缓冲有关的变量，然后当读到包数据的开始位置时，调用rtpInterface中保存的数据处理handler。还记得吧，rtpInterface中的这个数据处理handler在UDP时也被使用，在这个函数中要做的是读取一个包的数据，然后处理这个包。而SocketDescriptor把读取位置置于包数据开始的位置再交给数据处理handler，正好可以使用与UDP相同的数据处理handler！
还有，socketDescriptor们并不属于任何RTPInterface，而是单独保存在一个Hash table中，这样多个RTPInterface都可以注册到一个socketDescriptor中，以实现多路复用。
总结一下通过RTPInterface，live555不仅实现了rtp over udp，还实现了rtp over tcp，而且还实现了同时即有rtp over tcp，又有rtp over udp！
最后，channel id是从哪里来的呢？是在RTSP请求中指定的。在哪个请求中呢？自己找去吧。
数据库建设方案 数据库建设方案
原创粉丝点击
热门IT博客
影视后期 知乎影视后期 知乎
纸质笔记本 性价比知乎纸质笔记本 性价比知乎
大疆无人机香港知乎
p2p借款不还后果 知乎
数据库修改语句的in
linux端口流量统计
android会抛弃java吗
单片机与红外线
堆量选股公式 源码
张郃的死 知乎
w8怎么卸载软件
java eden
达尔文 蔡健雅 知乎
世界十大程序员
spring java应用
淘宝开店需要电脑吗
人工智能的英文作文
安装sql server 2008
分时量比曲线源码
ubuntu连打印机
热门问题 老师的惩罚 人脸识别 我在镇武司摸鱼那些年 重生之率土为王 我在大康的咸鱼生活 盘龙之生命进化 天生仙种 凡人之先天五行 春回大明朝 姑娘不必设防，我是瞎子 黄水晶手链价格 男生戴什么手链 串手链的珠子 玛瑙手链一般多少钱 海黄手链价格 小叶紫檀手链价格 石榴石手链价格 情侣手链品牌 今年流行手链 石榴石手链佩戴的忌讳 绿翡翠手链价格 手工手链绳的编法 手链扣怎么系 红玛瑙手链佩戴的忌讳 黄金翡翠手链 红色玛瑙手链价格 玉貔貅手链价格 绿松石手串 绳编手工教程大全 编手绳的方法图解 情侣手镯 爱心手环 两股绳的编法图解 水晶饰品 编手环的方法图解 在乎你情侣商城 负离子手环 绳编手工教程大全图解 珊瑚手串 玫瑰金多少钱一克 五彩绳的编法 编织 单根绳子编法大全图解 编红绳项链编法图解 手工编织绳 绳子编法大全图解 红绳项链编法图解 手工编绳教程 diy手绳编织教程 绳子编项链 项链绳的编法

程序博客网，程序员的互联网技术博客家园。csdn论坛精品 msdn技术资料都在这里