Live555源码解析(3)

上一篇Live555源码解析(2) - RTSP协议概述对RTSP进行了整体介绍，对会话交互过程及通常应用场景做了示例。接下来，我们就从媒体服务器的本职工作服务开始谈起。

1. 从服务器说起

要服务，就必须有服务器，有开放给外界客户端访问的地址和端口。先放源码：

TaskScheduler* scheduler = BasicTaskScheduler::createNew();UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler);UserAuthenticationDatabase* authDB = NULL;portNumBits rtspServerPortNum = 554;//@1 建立RTSP服务器RTSPServer* rtspServer = DynamicRTSPServer::createNew(*env, rtspServerPortNum, authDB);if(rtspServer == NULL){    rtspServerPortNum = 8554;    rtspServer = DynamicRTSPServer::createNew(*env, rtspServerPortNum, authDB);}if(rtspServer == NULL){    *env << "Failed to create RTSP server: " << env->getResultMsg() << "\n";    exit(1);}

源码分析：

• @1 建立RTSP服务器
  createNew()函数有三个参数，分别说明如下：

  • *env
    env对应的UsageEnvironment、BasicUsageEnvironment主要为后台运行机制，提供基础支持。具体已在本系列Live555源码解析(1) - Main 寻根问祖，留其筋骨中详细说明，这里不再赘述。
  • rtspServerPortNum
    RTSP默认知名端口为554，如被占用，则使用8554。如仍不能成功创建，则提示错误后退出程序。
  • authDB
    authDB对应UserAuthenticationDatabase，默认情况下不会定义ACCESS_CONTROL，即关闭认证机制。因此此处不进行分析，后续如有需求，可专门整理下互联网认证机制概况。

  本句代码中出现了两个class，分别为RTSPServer、DynamicRTSPServer。第一眼看应该是继承关系，确实也是继承关系，只不过希望先留个更清晰的印象。
  

2. DynamicRTSPServer::createNew()

源码：

DynamicRTSPServer* DynamicRTSPServer::createNew(UsageEnvironment& env, Port ourPort, UserAuthenticationDatabase* authDatabase, unsigned reclamationTestSeconds){    //@1 创建Socket    int ourSocket = setUpOurSocket(env, ourPort);    if (ourSocket == -1) return NULL;    //@2 DynamicRTSPServer构造函数    return new DynamicRTSPServer(env, ourSocket, ourPort, authDatabase, reclamationTestSeconds);}

源码分析：

• @1 创建Socket
  由于RTSPServer、RTSPServerSupportingHTTPStreaming、DynamicRTSPServer均为实现setUpOurSocket()函数，因此这里实际调用的是父类GenericMediaServer中的setUpOurSocket()。

  int GenericMediaServer::setUpOurSocket(UsageEnvironment& env, Port& ourPort){    int ourSocket = -1;    do    {        //如果当前Socket已被本地服务器占用，则不允许重复使用        NoReuse dummy(env);        //@1.1 创建TCPSocket        ourSocket = setupStreamSocket(env, ourPort);        if(ourSocket < 0) break;        //@1.2 调整Socket发送Buffer大小        if(!increaseSendBufferTo(env, ourSocket, 50*1024)) break;        //@1.3 切换Socket模式为LISTEN        if(listen(ourSocket, LISTEN_BACKLOG_SIZE) < 0)        {            env.setResultErrMsg("listen() failed: ");            break;        }        //@1.4 校验port值        if(ourPort.num() == 0)            if(!getSourcePort(env, ourSocket, ourPort)) break;        return ourSocket;    } while(0);    //@1.5 异常情况，清场退出    if(ourSocket != -1) ::closeSocket(ourSocket);    return -1;}

  • @1.1 创建TCPSocket
    GroupsockHelper中定义了Socket的一些全局帮助函数，使用时inlcude “GroupsockHelper.hh”即可，如此处的setupStreamSocket。

    int setupStreamSocket(UsageEnvironment& env, Port port, Boolean makeNonBlocking){    //@1.1.1 winsock使用前初始化    if(!initializeWinsockIfNecessary())    {        socketErr(env, "Failed to initialize 'winsock': ");        return -1;    }    //@1.1.2 创建IPv4 Socket    int newSocket = createSocket(SOCK_STREAM);    if(newSocket < 0)    {        socketErr(env, "unable to create stream socket: ");        return newSocket;    }    //@1.1.3 SO_REUSEADDR    int reuseFlag = groupsockPriv(env)->reuseFlag;    reclaimGroupsockPriv(env);    if(setsockopt(newSocket, SOL_SOCKET, SO_REUSEADDR, (const char*)&reuseFlag, sizeof  reuseFlag) < 0)    {        socketErr(env, "setsockopt(SO_REUSEADDR) error: ");        closeSocket(newSocket);        return -1;    }    //@1.1.4 SO_REUSEPORT    if(setsockopt(newSocket, SOL_SOCKET, SO_REUSEPORT, (const char*)&reuseFlag, sizeof reuseFlag) < 0)    {        socketErr(env, "setsockopt(SO_REUSEPORT) error: ");        closeSocket(newSocket);        return -1;    }    // 如已制定Port或Addr，则需显式bind()至创建的socket    if(port.num() != 0 || ReceivingInterfaceAddr != INADDR_ANY)    {        MAKE_SOCKADDR_IN(name, ReceivingInterfaceAddr, port.num());        if(bind(newSocket, (struct sockaddr*)&name, sizeof name) != 0)        {            char tmpBuffer[100];            sprintf(tmpBuffer, "bind() error(port number: %d): ", ntohs(port.num());            socketErr(env, tmpBuffer);            closeSocket(newSocket);            return -1;        }    }    //@1.1.5 non-blocking    if(makeNonBlocking)    {        if(!makeSocketNonBlocking(newSocket))        {            socketErr(env, "failed to make non-blocking: ");            closeSocket(newSocket);            return -1;        }    }    return newSocket;}

    • @1.1.1 winsock使用前初始化
      winsock使用前必须调用初始化命令，通过WSAStartup()设置Socket最高版本。这里尝试2.2和1.1版本，成功即可。
      源码位于groupsock/inet.c中。

    • @1.1.2 创建IPv4 Socket
      调用socket()函数创建指定类型的IPv4 Socket，此处为SOCK_STREAM即TCP Socket。

      sock = socket(AF_INET, type|SOCK_CLOEXEC, 0);

      注意到此处尝试设置SOCK_CLOEXEC属性，@Sniper what’s the SOCK_CLOEXEC。

    • @1.1.3 SO_REUSEADDR
      设置SO_REUSEADDR Flag，TCP的最主要目标是保证数据传输的可靠性，即使出现了分组丢失、分组乱序甚至这里相关的分组重复。想象一下，当TCP连接中，出现了分组丢失，在2RTT后通常会重传保证数据可靠。完成连接任务后，TCP开始进行四路断开，不幸的是，此时原迷路（被路由到其他网络）的分组又被路由回来了。那么TCP应该如何对待这个分组？
      如果不允许重用地址，也就是说不设置SO_REUSEADDR标志，那么TCP连接将保持处于TIME_WAIT状态2MSL时间以善后可能如上述出现的分组重复情况。2MSL（通常为30~120秒）内，所有重复分组直接被丢弃。如重复分组在2MSL时长内仍未到达，则将自然消亡，因此连接安全退出。
      看起来，这是一种安全机制，保证了重复分组可以得到正确处理，但实践中发生上述情况的概率很小，而如果均采取上述操作会引入新的麻烦。比如服务器所在主机异常重启，服务进程被动重启，此时如不允许地址重用，则需等待2MSL，也就是说30~120秒，这个时长内，无法提供正常服务。这个代价是没有必要的，而后者出现的概率比前者要更容易的多。
      因此，不管是BSD socket还是Windows Winsock，通常都会设置SO_REUSEADDR标志，当然必须在bind()前设置才能生效。

    • @1.1.4 SO_REUSEPORT
      SO_REUSEPORT支持多个进程或者线程绑定到同一端口，以提高服务器程序的性能，它解决了如下问题：

      • 允许多个套接字bind()/listen() 同一个TCP/UDP端口

        • 每一个线程拥有自己的服务器套接字
        • 在服务器套接字上没有了锁的竞争
      • 内核层面实现负载均衡
      • 安全层面，监听同一个端口的套接字只能位于同一个用户下面

    • @1.1.5 non-blocking
      默认情况下，TCP socket是阻塞(blocking)模式的，例如当你调用recv()来读取流数据时，该函数会直到至少有一个字节数据可读或出现异常错误才会返回。而非阻塞(non-blocking)模式时，操作不必等到有结果才返回，而是以异步的形式在满足条件后返回，这对于处理多个socket时非常有效。

    所以至此，如成功从setupStreamSocket()返回，那么我们得到的一定是一个具有CLOEXEC、REUSEADDR、REUSEPORT且non-blocking的Socket。

  • @1.2 调整Socket发送Buffer大小
    确保Socket发送Buffer足够大，这里设置为50KB。同样内部是通过GroupsockHelper提供的帮助函数完成的。这里想具体说下为什么要有缓存的存在。
    众所周知，TCP的卖点在可靠性，可靠不意味着不出错，否则IP协议就足够传输了。可靠值得是容错的能力很强，既然要容错，就必须有备份，否则无法支持重传、滑动窗口、拥塞控制等机制运行。既然有备份，那就必须有缓存，也就是说buffer的存在。事实上，每个Socket都拥有自己的Receive Buffer和Send Buffer，对应Read和Write操作。顺便说明一下，Read/Write返回仅仅是指和Buffer的交互过程完成，比如Write所有数据到Send Buffer后即可返回成功，而从Send Buffer到对端Receive Buffer，则需要由TCP协议内部众多机制参与完成。

  • @1.3 切换Socket模式为LISTEN
    socket创建后默认为主动状态，而listen()用于将socket切换为被动监听状态。所谓被动监听，是指当无客户端请求时，socket处于睡眠状态，直到出现请求，才会被唤醒来响应请求。
    

    需要注意的是第二个参数LISTEN_BACKLOG_SIZE，它代表着内核应该为相应socket排队的最大连接个数。通常内核为每个socket维护两个队列：

    • 未完成连接队列
    • 已完成连接队列

    
    此处图片及内容参考或截取自《Unix网络编程卷1》p107，这是本好书，建议阅读。

  • @1.4 校验port值
    如未指定port值，则有内核确认port端口，此时应显式获取，更新变量ourPort以便后续使用。

  自此，第一部分setUpOurSocket操作完成，收获的是端口号为554或8554，具有CLOEXEC、REUSEADDR、REUSEPORT且non-blocking标志，发送缓存为50KB，已切换至Listen状态的Socket。

• @2 DynamicRTSPServer构造函数
  有了静态的Socket后，就有了对外提供服务的渠道或窗口，但服务本身并未建设完成，因此第二部分的工作就是铺设基础服务。

  DynamicRTSPServer::DynamicRTSPServer(UsageEnvironment& env, int ourSocket, Port ourPort,        UserAuthenticationDatabase* authDatabase, unsigned reclamtionTestSeconds)    //@2.1 RTSPServerSupportingHTTPStreaming构造函数    : RTSPServerSupportingHTTPStreaming(env, ourSocket, ourPort, authDatabase, reclamationTestSeconds){}

  第一小节中，已经给出了DynamicRTSPServer和RTSPServer等类间继承关系图，结合这段代码，也可以看出除了调用基类RTSPServerSupportingHTTPStreaming构造函数外，并无其他内容。

  • @2.1 RTSPServerSupportingHTTPStreaming构造函数
    类似地，除调用基类构造函数外，无其他初始化内容。

    RTSPServerSupportingHTTPStreaming::RTSPServerSupportingHTTPStreaming(UsageEnvironment& env,                 int ourSocket, Port rtspPort, UserAuthenticationDatabase* authDatabase,         unsigned reclamationTestSeconds)//@2.1.1 RTSPServer构造函数: RTSPServer(env, ourSocket, rtspPort, authDatabase, reclamationTestSeconds) {}

    • @2.1.1 RTSPServer构造函数

      RTSPServer::RTSPServer(UsageEnvironment& env, int ourSocket, Port ourPort,              UserAuthenticationDatabase* authDatabase,            unsigned reclamationSeconds)//@2.1.1.1 GenericMediaServer构造函数: GenericMediaServer(env, ourSocket, ourPort, reclamationSeconds), fHTTPServerSocket(-1), fHTTPServerPort(0), fAllowStreamingRTPOverTCP(True), fClientConnectionsForHTTPTunneling(NULL) // will get created if needed, fTCPStreamingDatabase(HashTable::create(ONE_WORD_HASH_KEYS)), fPendingRegisterOrDeregisterRequests(HashTable::create(ONE_WORD_HASH_KEYS)), fRegisterOrDeregisterRequestCounter(0)//@2.1.1.2 认证机制, fAuthDB(authDatabase){}

      • @2.1.1.1 GenericMediaServer构造函数

        GenericMediaServer::GenericMediaServer(UsageEnvironment& env, int ourSocket,                                        Port ourPort, unsigned reclamationSeconds)//@2.1.1.1.1 Medium构造函数: Medium(env), fServerSocket(ourSocket), fServerPort(ourPort) , fReclamationSeconds(reclamationSeconds)//@2.1.1.1.2 HASH Tables, fServerMediaSessions(HashTable::create(STRING_HASH_KEYS)), fClientConnections(HashTable::create(ONE_WORD_HASH_KEYS)), fClientSessions(HashTable::create(STRING_HASH_KEYS)){    //@2.1.1.1.3 ignore SIGPIPE信号    ignoreSigPipeOnSocket(fServerSocket);     //@2.1.1.1.4 铺设服务-incomingConnectionHandler    env.taskScheduler().turnOnBackgroundReadHandling(fServerSocket,                                     incomingConnectionHandler, this); }

        • @2.1.1.1.1 Medium构造函数

          Medium::Medium(UsageEnvironment& env): fEnviron(env), fNextTask(NULL) {    MediaLookupTable::ourMedia(env)->generateNewName(fMediumName, mediumNameMaxLen);    env.setResultMsg(fMediumName);    MediaLookupTable::ourMedia(env)->addNew(this, fMediumName);}

          根父类，是Media Server中大多数类的父类。MediaLookupTable是一个类，主要用于方便根据名称进行Medium的查找，内部使用，不进行详细说明。
          

        • @2.1.1.1.2 HASH Tables
          顾名思义，三张表分别保存着服务器媒体会话、客户端连接以及客户端会话。各表内容变动API分别为：

          • ServerMediaSessions

            • addServerMediaSession()
            • removeServerMediaSession()

          • ClientConnections

            • ClientConnection()构造函数
            • ~ClientConnection()析构函数

          • ClientSessions

            • createNewClientSessionWithId()
            • closeAllClientSessionsForServerMediaSession()

        • @2.1.1.1.3 ignore SIGPIPE信号
          先说明下SIGPIPE信号如何产生：当socket对端已调用close进行了完全关闭时，本地Write发出的保温会导致对端回复RST报文，假如本地再次调用Write，则会生成SIGPIPE信号，导致进程退出。
          为了避免进程退出，既可以捕获SIGPIPE信号对其进行处理，也可以简单忽略。这样第二次调用Write时会返回-1，且错误值设为SIGPIPE，以便程序知道对端已经关闭。

        • @2.1.1.1.4 铺设服务-incomingConnectionHandler

          实际调用UsageEnvironment中TaskScheduler类的成员函数。

          void turnOnBackgroundReadHandling(int socketNum,                BackgroundHandlerProc* handlerProc, void* clientData) {    setBackgroundHandling(socketNum, SOCKET_READABLE,                            handlerProc, clientData);}

          该函数又在BasicTaskScheduler类中实现。

          void BasicTaskScheduler::setBackgroundHandling(int socketNum,    int conditionSet, BackgroundHandlerProc* handlerProc, void* clientData){    if(socketNum < 0) return;    FD_CLR((unsigned)socketNum, &fReadSet);    FD_CLR((unsigned)socketNum, &fWriteSet);    FD_CLR((unsigned)socketNum, &fExceptionSet);    if(conditionSet == 0)    {        fHandlers->clearHandler(socketNum);        if(socketNum+1 == fMaxNumSockets)            --fMaxNumSockets;    }    else    {        fHandlers->assignHandler(socketNum, conditionSet, handlerProc, clientData);        if(socketNum+1 > fMaxNumSockets)            fMaxNumSockets = socketNum + 1;        if(conditionSet&SOCKET_READABLE) FD_SET((unsigned)socketNum, &fReadSet);        if(conditionSet&SOCKET_WRITABLE) FD_SET((unsigned)socketNum, &fWriteSet);        if(conditionSet&SOCKET_EXCEPTION) FD_SET((unsigned)socketNum, &fExceptionSet);    }                           }

        如果你还能记得Live555源码解析(1) - Main 寻根问祖，留其筋骨提到main()函数中的Loop SingleStep()，那么ReadSet、WriteSet、ExceptionSet一定还有印象。事实上，这三个Set用于多Sockets Select。

        还需要注意的一句是assignHandler()，作用对象为fHandlers，该对象类型为HandlerSet*，同样在Live555源码解析(1) - Main 寻根问祖，留其筋骨中也有详细说明，此处不再赘述。

        只需要记住，Set和fHandlers两个变量配合的结果是为了当socket满足指定条件时，调用设定的处理函数。对应到此处，是指当Socket可读时，调用incomingConnectionHandler函数。完成判断、调用逻辑的实现，就在BasicTaskScheduler::SingleStep()中Socket I/O循环部分。

      • @2.1.1.2 认证机制
        虽然本篇并不讨论认证机制，但仍然需要注意的是，认证机制在这一层完成。

3. 总结

从前面两节的代码分析来看，暂时只铺设了一项服务incomingConnectionHandler，同时准备了一些哈希表以供程序运行中使用，分别为ServerMediaSessions、ClientConnections、ClientSessions，也在@2.1.1.1.2 HASH Tables小节中列出了会修改表内容的API。这就是能从DynamicRTSPServer create所发掘的所有动线。

下一篇中，将基于这项服务，寻找服务的使用动机、时机，以及所引起的其他连锁反应。