Android 4.2 Wifi Display核心分析 （一）

作者： Wolf Geek     转载请说明出处

        上一回，主要介绍了有关WifiDisplay设备连接和建立数据流的流程，这一回将接着向底层前进。由于涉及的内容较多，这里仅仅理清一个大概的头绪，细节的部分将不再展开，如果有什么错误的地方我会及时更正。

       当Source端通过RemoteDisplay.cpp的构造函数注册了Wifidisplay处理线程，并且ANetworkSession初始化了通信所用的数据管道并且开始监听数据流变化后，Source端将通过函数mSource->start(iface)开始建立RTSP连接并且向Sink端传递数据流。接下来，将具体分析其流程。mSource->start(iface)的具体实现在以下文件，

 frameworks/av/media/libstagefright/wifi-display/source/WifiDisplaySource.cpp

 status_t WifiDisplaySource::start(const char *iface) {
     CHECK_EQ(mState, INITIALIZED);

     sp<AMessage> msg = new AMessage(kWhatStart, id());
     msg->setString("iface", iface);

     sp<AMessage> response;
     status_t err = msg->postAndAwaitResponse(&response);

     if (err != OK) {
         return err;
     }

     if (!response->findInt32("err", &err)) {
         err = OK;
     }

     return err;
 }

该函数首先通过CHECK_EQ来判断当前Source端状态是否为 INITIALIZED，如果是将通过 AMessage创建 标识为kWhatStart的消息，用于在onMessageReceived处理分支中进行匹配，msg->setString(“iface”,iface)用于在传递消息过程中携带网络地址端口信息， msg->postAndAwaitResponse用于返回相应结果。这种方式在Android的流媒体类中相当常见，是一种异步消息处理框架。与该框架相关的类主要有ALooper、AHandler、ALooperRoster等，具体请见这里。

接下来，我们来看看当Source端接收到kWhatStart的消息后做何种处理，

 void WifiDisplaySource::onMessageReceived(const sp<AMessage> &msg) {
     switch (msg->what()) {
         case kWhatStart:
         {
             uint32_t replyID;
             CHECK(msg->senderAwaitsResponse(&replyID));

             AString iface;
             CHECK(msg->findString("iface", &iface));

             status_t err = OK;

             ssize_t colonPos = iface.find(":");  //寻找“:”所在位置

             unsigned long port;

             if (colonPos >= 0) {
                 const char *s = iface.c_str() + colonPos + 1;

                 char *end;
                 port = strtoul(s, &end, 10);  //得到port号

                 if (end == s || *end != '\0' || port > 65535) {
                     err = -EINVAL;
                 } else {
                     iface.erase(colonPos, iface.size() - colonPos);
                 }
             } else {
                 port = kWifiDisplayDefaultPort;
             }

             if (err == OK) {
                 if (inet_aton(iface.c_str(), &mInterfaceAddr) != 0) {  //将IP地址转化为32位的网络序列IP地址
                     sp<AMessage> notify = new AMessage(kWhatRTSPNotify, id());//建立标识为 kWhatRTSPNotify的消息作为参数传递

                     err = mNetSession->createRTSPServer(
                             mInterfaceAddr, port, notify, &mSessionID);
                 } else {
                     err = -EINVAL;
                 }
             }

             if (err == OK) {
                 mState = AWAITING_CLIENT_CONNECTION;
             }

             sp<AMessage> response = new AMessage;
             response->setInt32("err", err);
             response->postReply(replyID);
             break;
         }
       ...
    }
 }

首先，可以看到当Source端接收到消息标识为 kWhatStart的消息后，消息指针msg会通过函数msg->senderAwaitsResponse(&replyID)获取对应于postAndAwaitResponse函数的响应标识，并把处理中的错误信息作为消息载体通过response->postReply(replyID)传递回start(iface)函数。然后，该处理函数将接收到的网络地址端口信息iface拆分为IP地址和端口两个部分,并且利用 createRTSPServer创建RTSP服务端，函数会返回相应的Session编号。如果RTSP服务端创建成功，则将Source端状态更改为 AWAITING_CLIENT_CONNECTION，表示等待客户端连接。

 接着看创建RTSP服务端具体做了哪些动作，

frameworks/av/media/libstagefright/wifi-display/ANetworkSession.cpp

 status_t ANetworkSession::createRTSPServer(
         const struct in_addr &addr, unsigned port,
         const sp<AMessage> notify, int32_t *sessionID) {
     return createClientOrServer(
             kModeCreateRTSPServer,
             &addr,
             port,
             NULL /* remoteHost */,
             0 /* remotePort */,
             notify,
             sessionID);
 }

可以看到函数createRTSPServer具体又调用了 createClientOrServer函数。在此类中，与建立管道数据流相关的函数都会调用该函数，它们分别是createRTSPClient、createRTSPServer、createUDPSession、createTCPDatagramSession等函数。

其中可以不用关注函数createTCPDatagramSession，这是因为Sink端默认选择了UDP方式进行传输。具体起关键性作用的是在WifiDisplaySink.h头文件中的static const bool sUseTCPInterleaving = false变量 ，具体而言，该变量为false就导致Sink端不会向Source端发送“Transport: RTP/AVP/TCP”这样的请求，这样在Source端就不会将Sender类中的mTransportMode变量设置为TRANSPORT_TCP或者 TRANSPORT_TCP_INTERLEAVED，所以在Sender类中最终并不会调用函数createTCPDatagramSession。        

接下来，将重点看看函数createClientOrServer，其中与建立RTSP服务端无关的步骤先省略不看。

 status_t ANetworkSession::createClientOrServer(
         Mode mode,
         const struct in_addr *localAddr,
         unsigned port,
         const char *remoteHost,
         unsigned remotePort,
         const sp<AMessage> notify,
         int32_t *sessionID) {
     Mutex::Autolock autoLock(mLock);

     *sessionID = 0;
     status_t err = OK;
     int s, res;
     sp<Session> session;

     s = socket(
             AF_INET,
             (mode == kModeCreateUDPSession) ? SOCK_DGRAM : SOCK_STREAM,
             0);    //建立类型为流套接字的socket

   ...

     if (mode == kModeCreateRTSPServer
             || mode == kModeCreateTCPDatagramSessionPassive) {
         const int yes = 1;
         res = setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));//允许socket和一个已在使用中的地址捆绑
     err = MakeSocketNonBlocking(s);  //设置socket为非阻塞方式

     struct sockaddr_in addr;
     memset(addr.sin_zero, 0, sizeof(addr.sin_zero));
     addr.sin_family = AF_INET;

     if (mode == kModeCreateRTSPClient
             || mode == kModeCreateTCPDatagramSessionActive) {
      ...
     } else if (localAddr != NULL) {
         addr.sin_addr = *localAddr;
         addr.sin_port = htons(port);
     } else {
         ...
     }

     if (mode == kModeCreateRTSPClient
             || mode == kModeCreateTCPDatagramSessionActive) {
        ...

     } else {
         res = bind(s, (const struct sockaddr *)&addr, sizeof(addr));//socket与
 sockaddr结构体指针绑定，sockaddr对应与iface
         if (res == 0) {  //绑定成功
             if (mode == kModeCreateRTSPServer
                     || mode == kModeCreateTCPDatagramSessionPassive) {
                 res = listen(s, 4);  //作为服务端开始监听rtsp连接请求
             } else {
                   ...
                 }
             }
         }
     }
      ...
     Session::State state;
     switch (mode) {
         ...

         case kModeCreateRTSPServer:
             state = Session::LISTENING_RTSP;   //设置Session状态为 LISTENING_RTSP
             break;
        ...
     }

     session = new Session(
             mNextSessionID++,
             state,
             s,
             notify);    //创建一个session对象,sessionID加1

     ...
     mSessions.add(session->sessionID(), session); //将该对象加入vector结构中保存

     interrupt();  //向管道写端写数据

     *sessionID = session->sessionID();  //由指针带出当前sessionID

     goto bail;
 ...

 bail:
     return err;
 }

可以看到建立RTSP服务端的步骤没什么特别的地方，无非是建立socket,绑定地址然后监听等步骤，只不过为了标识不同的请求和区分当前状态，这里用Session结构体和相应的状态来管理对应的socket。

回到RemoteDisplay.cpp的构造函数中，可以看到在Source端调用函数mSource->start(iface)之前就通过mNetSession->start()开启了ANetworkSession线程，接下来看一下mNetSession->start()究竟干了什么事。

 status_t ANetworkSession::start(){
    ...
    int res =pipe(mPipeFd);  //建立读写管道，控制threadLoop的执行
    if (res != 0) {
         mPipeFd[0] = mPipeFd[1] = -1;
         return -errno;
    }
    mThread = new NetworkThread(this); //构造ANetworkSession的内部结构线程
    status_t err = mThread->run("ANetworkSession", ANDROID_PRIORITY_AUDIO);//开启该线程，将会调用NetworkThread线程中threadLoop，进一步会调用AnetworkSession::threadLoop()
    ...
    return OK;
 }

    可以看到ANetworkSession采用了管道的方式来控制AnetworkSession::threadLoop()的执行，

 void ANetworkSession::threadLoop() {
     fd_set rs, ws;
     FD_ZERO(&rs);
     FD_ZERO(&ws);
     FD_SET(mPipeFd[0], &rs);
     int maxFd = mPipeFd[0];
     {
       ...
         for (size_t i = 0; i < mSessions.size(); ++i) {
             const sp<Session> &session = mSessions.valueAt(i);
             int s = session->socket();    //遍历并获取vector结构中保存的socket
             ...
             if (session->wantsToRead()) {  //判断当前session状态是否需要读
                 FD_SET(s, &rs);
                 if (s > maxFd) {
                     maxFd = s;
                 }
             }
             if (session->wantsToWrite()) {//判断当前session状态是否需要写
                 FD_SET(s, &ws);
                 if (s > maxFd) {
                     maxFd = s;
                 }
             }
         }
     }
         int res = select(maxFd + 1, &rs, &ws, NULL, NULL ); //阻塞查看是否有socket可读写
           ...

     if (FD_ISSET(mPipeFd[0], &rs)) {
         char c;
         ssize_t n;
         do {
                     n = read(mPipeFd[0], &c, 1);  //只有当管道中有数值时才跳出循环，即类中有其他函数调用了 interrupt函数
         } while (n < 0 && errno == EINTR);
         ...
         --res;
     }

     {
         ...
         List<sp<Session> > sessionsToAdd;
         for (size_t i = mSessions.size(); res > 0 && i-- > 0;) { //res>0判断是否有socket资源可进行读或写
             const sp<Session> &session = mSessions.valueAt(i);
             int s = session->socket();

             if (FD_ISSET(s, &rs) || FD_ISSET(s, &ws)) {
                 --res;
             }
             if (FD_ISSET(s, &rs)) {
                 if (session->isRTSPServer() || session->isTCPDatagramServer()) {
 //如果当前状态Session状态为LISTENING_RTSP或LISTENING_TCP_DGRAMS执行下列操作
                     struct sockaddr_in remoteAddr;
                     socklen_t remoteAddrLen = sizeof(remoteAddr);

                     int clientSocket = accept(
                             s, (struct sockaddr *)&remoteAddr, &remoteAddrLen);//从处于listen状态的流套接字s的客户连接请求队列中取出排在最前的一个客户请求建立新的socket通道
                     if (clientSocket >= 0) {
                         status_t err = MakeSocketNonBlocking(clientSocket);
                          ...

                             sp<Session> clientSession =
                                 new Session(
                                         mNextSessionID++,
                                         Session::CONNECTED,
                                         clientSocket,
                                         session->getNotificationMessage());
 //把所建立RTSP连接的本地地址、客户地址以及端口等信息通过AMessage发送到Source端
                             clientSession->setIsRTSPConnection(
                                     session->isRTSPServer());  //mIsRTSPConnection变量设为false
                   sessionsToAdd.push_back(clientSession);  //将该Session加入到 sessionsToAdd队列尾部
                     }
                         ...
                 } else {
                     status_t err = session->readMore(); //在建立UDP连接或者RTSP连接已建立的状况且该socket可读，接收相应socket传来的信息，同时通过AMessage的形式与Source或Sink端做数据交换并且通知其做相应处理
                 }
             }
             if (FD_ISSET(s, &ws)) {
                 status_t err = session->writeMore();  //对有写需求的Session,并且该socket是可写的情况下，向UDP或RTSP连接的另一端发送由Souce或Sink端相应请求中获得的数据
           ...
             }
         }
         while (!sessionsToAdd.empty()) {
             sp<Session> session = *sessionsToAdd.begin();
             sessionsToAdd.erase(sessionsToAdd.begin());
             mSessions.add(session->sessionID(), session);  //按队列顺序把相关Session加入vector结构中保存
         }
     }
 }
 }

 该 threadLoop()函数首先完成了Sink端RTSP客户端连接请求的接收，其次还负责完成在Source端和Sink端之间的RTSP连接和UDP连接的相关socket读写通信等工作。了解了ANetworkSession线程是如何管理Source端和Sink端之间数据通信的过程后，再次回到Wifi Display的开启流程上来。在threadLoop()函数中RTSP服务端会从处于listen状态的流套接字s的客户连接请求队列中取出排在最前的一个客户请求建立新的socket通道。可以看到这个连接请求由rtsp的客户端发出，具体而言，该请求是由createClientOrServer函数中相应的connect函数完成，

frameworks/av/media/libstagefright/wifi-display/ANetworkSession.cpp

 if (mode == kModeCreateRTSPClient
             || mode == kModeCreateTCPDatagramSessionActive) {
         struct hostent *ent= gethostbyname(remoteHost);
         addr.sin_addr.s_addr = *(in_addr_t *)ent->h_addr;
         addr.sin_port = htons(remotePort);
         in_addr_t x = ntohl(addr.sin_addr.s_addr);
         ALOGI("connecting socket %d to %d.%d.%d.%d:%d",
               s,
               (x >> 24),
               (x >> 16) & 0xff,
               (x >> 8) & 0xff,
               x & 0xff,
               ntohs(addr.sin_port));

         res = connect(s, (const struct sockaddr *)&addr, sizeof(addr));
     }

到这里，关注的焦点转向到createRTSPClient也就是Rtsp客户端建立的过程，而客户端的建立是由Sink端完成的，因此开始分析Sink端程序。

客户端主程序目前只有测试程序，由于没有设备并没有进行相关测试，该程序编译好只能以命令方式运行，命令有两个选项作为选择,调用格式如下，

./wfd -c xx.xx.xx.xx:port

./wfd -u uri

第一条命令用于将Sink端连接到Source端，需要知道Source端的IP地址及Port端口，第二条命令用于测试sink端连接到rtsp uri地址的效果。这里只来看第一条命令，执行后其会调用以下关键的几个函数，

frameworks/av/media/libstagefright/wifi-display/wfd.cpp

 sp<ANetworkSession> session = new ANetworkSession;
 session->start();
 sp<WifiDisplaySink> sink = new WifiDisplaySink(session);
 looper->registerHandler(sink);
 sink->start(connectToHost.c_str(), connectToPort);
  looper->start(true);

可以看到，Sink端的启动与Source端没有什么区别，依旧是开启如同RemoteDisplay.cpp中的那几个线程，下面来关注一下WifiDisplaySink线程的启动。首先是用构造函数new出一个操作对象，以下是构造函数，

 WifiDisplaySink::WifiDisplaySink(
         const sp<ANetworkSession> &netSession,
         const sp<ISurfaceTexture> &surfaceTex)
     : mState(UNDEFINED),
       mNetSession(netSession),
       mSurfaceTex(surfaceTex),
       mSessionID(0),
       mNextCSeq(1) {
 }

上面为WifiDisplaySink的构造函数，可以看到调用时并没有去初始化第二个参数，默认就会被置为空，这是为用户自己构造Sink端程序界面提供的参数。后面会看到在TunnelRenderer类中会直接创建Surface对象供填充Sink端播放器使用。也就是说，如果要写自己的Sink端应用，可以将应用层要作为显示Source端数据流的Surface直接用来填充该构造函数使用。之后就是利用构造出的对象去启动Sink端主线程，

 void WifiDisplaySink::start(const char *sourceHost, int32_t sourcePort) {
    sp<AMessage> msg = new AMessage(kWhatStart, id());
    msg->setString("sourceHost", sourceHost);
    msg->setInt32("sourcePort", sourcePort);
    msg->post();

 又看到了熟悉的异步消息处理框架AMessage类，这里就直接去看onMessageReceived的相应处理，

 void WifiDisplaySink::onMessageReceived(const sp<AMessage> &msg) {
     switch (msg->what()) {
         case kWhatStart:
         {
             int32_t sourcePort;

                   ...
                 CHECK(msg->findString("sourceHost", &mRTSPHost));
                 CHECK(msg->findInt32("sourcePort", &sourcePort));

             sp<AMessage> notify = new AMessage(kWhatRTSPNotify, id());

             status_t err = mNetSession->createRTSPClient(
                     mRTSPHost.c_str(), sourcePort, notify, &mSessionID);
 //建立RTSP客户端
             CHECK_EQ(err, (status_t)OK);

             mState = CONNECTING;
             break;
         }
         ...
      }

 }

到此，终于看到了Sink端调用ANetworkSession类中的createRTSPClient函数去建立Rtsp客户端。具体就是调用上面提到的connect函数将流套接字s连接至由命令指定的source端网络地址，并且将当前Session状态置为Session::CONNECTING。需要注意的是，只要调用了createClientOrServer的函数都会根据当前不同状态创建session并且加入到mSessions这一Vector结构中以供threadLoop和sendRequest等函数使用。当建立完RTSP服务端和客户端后，与RTSP服务端对应的session是需要读的，相应socket被加入到读文件描述符集合rs中；与RTSP客户端对应的session是需要写的，相应socket被加入到写文件描述符集合ws中。

 Rtsp服务端在监听到客户端连接请求后，在threadLoop中将调用accept函数接收该请求并创建新的clientSocket。如果clientSocket可以被置为非阻塞状态，则通过其创建clientSession，具体就是调用Session的构造函数 sp<Session> clientSession =new Session(mNextSessionID++,Session::CONNECTED,clientSocket,session->getNotificationMessage())，

 ANetworkSession::Session::Session(
         int32_t sessionID,
         State state,
         int s,
         const sp<AMessage> notify)
     : mSessionID(sessionID),
       mState(state),
       mIsRTSPConnection(false),
       mSocket(s),
       mNotify(notify),
       mSawReceiveFailure(false),
       mSawSendFailure(false) {
   if (mState == CONNECTED) {
         struct sockaddr_in localAddr;
         socklen_t localAddrLen = sizeof(localAddr);
         int res = getsockname(
                 mSocket, (struct sockaddr *)&localAddr, &localAddrLen);//根据clientSocket获得本地网络地址
         CHECK_GE(res, 0);
         struct sockaddr_in remoteAddr;
         socklen_t remoteAddrLen = sizeof(remoteAddr);

         res = getpeername(
                 mSocket, (struct sockaddr *)&remoteAddr, &remoteAddrLen);//根据clientSocket获得连接到Rtsp服务端的客户端网络地址
         CHECK_GE(res, 0);

         in_addr_t addr = ntohl(localAddr.sin_addr.s_addr);
         AString localAddrString = StringPrintf(
                 "%d.%d.%d.%d",
                 (addr >> 24),
                 (addr >> 16) & 0xff,
                 (addr >> 8) & 0xff,
                 addr & 0xff);

         addr = ntohl(remoteAddr.sin_addr.s_addr);
         AString remoteAddrString = StringPrintf(
                 "%d.%d.%d.%d",
                 (addr >> 24),
                 (addr >> 16) & 0xff,
                 (addr >> 8) & 0xff,
                 addr & 0xff);

         sp<AMessage> msg = mNotify->dup();  //利用AMessage进行通知
         msg->setInt32("sessionID", mSessionID);
         msg->setInt32("reason", kWhatClientConnected);  //通知Source端相关信息
         msg->setString("server-ip", localAddrString.c_str());
         msg->setInt32("server-port", ntohs(localAddr.sin_port));
         msg->setString("client-ip", remoteAddrString.c_str());
         msg->setInt32("client-port", ntohs(remoteAddr.sin_port));
         msg->post();
     }
   }

可以看到，在创建clientSession时，session的状态被置为 CONNECTED，随后会根据clientSocket获得本地网络地址和连接到Rtsp服务端的客户端网络地址。在构造函数的最后会将相关信息通知Source端。此外，clientSession
Source端在创建RTSP服务端后就一直处于AWAITING_CLIENT_CONNECTION的状态，并且等待接收kWhatRTSPNotify类型的消息。当clientSession创建并向Source端发送通知消息后，Source端就在查询reason类型为kWhatClientConnected的消息。
frameworks/av/media/libstagefright/wifi-display/source/WifiDisplaySource.cpp

 case ANetworkSession::kWhatClientConnected:
                {
                    int32_t sessionID;
                    CHECK(msg->findInt32("sessionID", &sessionID));
                    if (mClientSessionID > 0) {  // mClientSessionID初始为0
                        ALOGW("A client tried to connect, but we already "
                              "have one.");
                        mNetSession->destroySession(sessionID);
                        break;
                    }
                    CHECK_EQ(mState, AWAITING_CLIENT_CONNECTION);  //检查状态

                    CHECK(msg->findString("client-ip", &mClientInfo.mRemoteIP));//接收clientSession传来的信息
                    CHECK(msg->findString("server-ip", &mClientInfo.mLocalIP));

                    if (mClientInfo.mRemoteIP == mClientInfo.mLocalIP) {
                      //出于安全考虑不接收由本地网络地址发来的连接
                        mNetSession->destroySession(sessionID);
                        break;
                    }

                    CHECK(msg->findInt32(
                                "server-port", &mClientInfo.mLocalPort));
                    mClientInfo.mPlaybackSessionID = -1;
                    mClientSessionID = sessionID;
                    ALOGI("We now have a client (%d) connected.", sessionID);
                    mState = AWAITING_CLIENT_SETUP;
                    status_t err = sendM1(sessionID);
                    CHECK_EQ(err, (status_t)OK);
                    break;
                }

  在Source端，onMessageReceived函数会接收由clientSession发送的通知消息，并且将Source端状态置为AWAITING_CLIENT_SETUP。与此同时，其会将clientSession对应的sessionID作为参数标识向RTSP服务端发送OPTIONS请求。

 status_t WifiDisplaySource::sendM1(int32_t sessionID) {
     AString request = "OPTIONS * RTSP/1.0\r\n";
     AppendCommonResponse(&request, mNextCSeq);  //添加基本消息，如时间、消息序号等等

     request.append(
             "Require: org.wfa.wfd1.0\r\n"
             "\r\n");

     status_t err =
         mNetSession->sendRequest(sessionID, request.c_str(), request.size());
 //向ANetworkSession发送数据等待threadLoop处理
     if (err != OK) {
         return err;
     }
     registerResponseHandler(
             sessionID, mNextCSeq, &WifiDisplaySource::onReceiveM1Response);
 //使用函数指针返回状态信息
     ++mNextCSeq;  //消息序号标识递增

     return OK;
 }

 进一步，ANetworkSession类中的sendRequest函数无非是将消息保存在mOutBuffer或者mOutDatagrams供writeMore函数使用。具体而言，当sendRequest函数调用完毕时，threadLoop中的select函数发现写文件描述符集合ws有写变化，即有socket可写。因而会调用session->writeMore()函数，该session对应于RTSP客户端，所处状态仍旧为Session::CONNECTING。因此，在调用writeMore函数时，会执行以下语句，

 status_t ANetworkSession::Session::writeMore() {
 ...
 if (mState == CONNECTING) {
         int err;
         socklen_t optionLen = sizeof(err);
         CHECK_EQ(getsockopt(mSocket, SOL_SOCKET, SO_ERROR, &err, &optionLen), 0);
         CHECK_EQ(optionLen, (socklen_t)sizeof(err));
         if (err != 0) {
             notifyError(kWhatError, -err, "Connection failed");
             mSawSendFailure = true;
             return -err;
         }
         mState = CONNECTED;
         notify(kWhatConnected);
         return OK;
     }
     CHECK_EQ(mState, CONNECTED);
     CHECK(!mOutBuffer.empty());
     ssize_t n;
     do {
         n = send(mSocket, mOutBuffer.c_str(), mOutBuffer.size(), 0); //客户端向服务端发送OPTIONS请求
     } while (n < 0 && errno == EINTR);

     status_t err = OK;

     if (n > 0) {
         mOutBuffer.erase(0, n);
     } else if (n < 0) {
         err = -errno;
     } else if (n == 0) {
         err = -ECONNRESET;
     }

     if (err != OK) {
         notifyError(true , err, "Send failed.");
         mSawSendFailure = true;
     }

     return err;
 }

由于RTSP客户端所处状态为Session::CONNECTING，因此执行if中的语句。这里首先获得相关socket的错误信息，如果没有任何错误信息，则更改RTSP客户端相应Session状态为 CONNECTED，并且会通知Sink端 kWhatConnected信息将Sink端的状态置为CONNECTED。之后，threadLoop函数会将clientSession加入到mSessions集合中，并等待接收由客户端发送来的请求信息。也就是在下一次threadLoop执行时，clientSession将会调用readMore函数从mSocket中接收由客户端发送的请求信息，具体过程如下，

 status_t ANetworkSession::Session::readMore() {
     ...
     char tmp[512];
     ssize_t n;
     do {
         n = recv(mSocket, tmp, sizeof(tmp), 0);   //接收客户端请求信息
     } while (n < 0 && errno == EINTR);

     status_t err = OK;

     if (n > 0) {
         mInBuffer.append(tmp, n);

     } else if (n < 0) {
         err = -errno;
     } else {
         err = -ECONNRESET;
     }

     if (!mIsRTSPConnection) {
                ...
     } else {
         for (;;) {
             size_t length;

             if (mInBuffer.size() > 0 && mInBuffer.c_str()[0] == '$') {
 //接收到类型为PlaybackSession::kWhatBinaryData且头部请求信息为'$'才会进入此判断体
                         ...

             }

             sp<ParsedMessage> msg =
                 ParsedMessage::Parse(
                         mInBuffer.c_str(), mInBuffer.size(), err != OK, &length);
 //解析处理RTSP消息

             if (msg == NULL) {
                 break;
             }

             sp<AMessage> notify = mNotify->dup();
             notify->setInt32("sessionID", mSessionID);
             notify->setInt32("reason", kWhatData);  //向Sink端发送类型为kWhatData的消息请求
             notify->setObject("data", msg);
             notify->post();
              ...
             mInBuffer.erase(0, length);

             if (err != OK) {
                 break;
             }
         }
     }

     if (err != OK) {
         notifyError(false /* send */, err, "Recv failed.");
         mSawReceiveFailure = true;
     }

     return err;
 }

该函数会首先接收客户端请求信息，然后利用解析类将信息解析成Sink端能够识别处理的信息，并且向Sink端发送类型为kWhatData的消息请求。现在先来看一下Sink端在接收到消息后是如何进行处理的，

 void WifiDisplaySink::onMessageReceived(const sp<AMessage> &msg) {
          ...
   case ANetworkSession::kWhatData:
                 {
                    onReceiveClientData(msg);  //调用消息处理函数

                     break;
                 }
           ...
 }
 void WifiDisplaySink::onReceiveClientData(const sp<AMessage> &msg) {
      int32_t sessionID;
     CHECK(msg->findInt32("sessionID", &sessionID));  //获得发送消息的sessionID
     sp<RefBase> obj;
     CHECK(msg->findObject("data", &obj));  //获得发送信息的object对象
     sp<ParsedMessage> data =
         static_cast<ParsedMessage *>(obj.get());  //根据object对象获取解析后的数据
     ALOGV("session %d received '%s'",
           sessionID, data->debugString().c_str());
     AString method;
     AString uri;
     data->getRequestField(0, &method);
     int32_t cseq;
     if (!data->findInt32("cseq", &cseq)) {     //获取send时加入的消息序号
         sendErrorResponse(sessionID, "400 Bad Request", -1 );
         return ERROR_MALFORMED;
     }

     if (method.startsWith("RTSP/")) {  //如果消息以"RTSP/"开头

         ResponseID id;
         id.mSessionID = sessionID;
         id.mCSeq = cseq;
         ssize_t index = mResponseHandlers.indexOfKey(id);  //根据 ResponseID获取注册时的mResponseHandlers在KeyedVector<ResponseID, HandleRTSPResponseFunc>这个数据结构中的位置
         if (index < 0) {
             ALOGW("Received unsolicited server response, cseq %d", cseq);
             return ERROR_MALFORMED;
         }

         HandleRTSPResponseFunc func = mResponseHandlers.valueAt(index); //根据位置获取注册的回复函数
         mResponseHandlers.removeItemsAt(index);

         status_t err = (this->*func)(sessionID, data);  //填充函数指针
          //判断回复中是否有错误信息
         CHECK_EQ(err, (status_t)OK);
     } else {
         AString version;
         data->getRequestField(2, &version);
         if (!(version == AString("RTSP/1.0"))) {  //判断RTSP协议版本是否正确
             sendErrorResponse(sessionID, "505 RTSP Version not supported", cseq);
             return;
         }

         if (method == "OPTIONS") {
             onOptionsRequest(sessionID, cseq, data);
         } else if (method == "GET_PARAMETER") {
             onGetParameterRequest(sessionID, cseq, data);
         } else if (method == "SET_PARAMETER") {
             onSetParameterRequest(sessionID, cseq, data);
         } else {
             sendErrorResponse(sessionID, "405 Method Not Allowed", cseq);
         }
     }
 }

首先，Sink端接收函数类型为kWhatData的消息请求，会调用onReceiveClientData函数进行消息处理。该函数在获得发送信息的object对象、sessionID（此时的sessionID对应于clientSession）等信息后，根据object对象获取解析后的数据。如果解析后的消息以"RTSP/"开头，注册的回复函数中也没有错误信息，那么就填充之前利用registerResponseHandler函数注册的函数指针，否则就匹配处理方法类型调用相关处理函数。由于函数sendM1发送的是 OPTIONS请求，这样会直接去匹配处理方法类型，从而会调用onOptionsRequest函数。

 void WifiDisplaySink::onOptionsRequest(
         int32_t sessionID,
         int32_t cseq,
         const sp<ParsedMessage> &data) {
     AString response = "RTSP/1.0 200 OK\r\n";
     AppendCommonResponse(&response, cseq);
     response.append("Public: org.wfa.wfd1.0, GET_PARAMETER, SET_PARAMETER\r\n");
     response.append("\r\n");

     status_t err = mNetSession->sendRequest(sessionID, response.c_str());
     CHECK_EQ(err, (status_t)OK);

     err = sendM2(sessionID);
     CHECK_EQ(err, (status_t)OK);
 }

该函数会将Sink端支持的方法GET_PARAMETER, SET_PARAMETER发送至ANetworkSession。以采取上面的那种readMore,writeMore之间socket通信的方式将Sink端支持的方法通知给Source端，Source端依旧采取形如Sink端的消息接收处理方式进行处理，

 

 void WifiDisplaySource::onMessageReceived(const sp<AMessage> &msg) {
          ...
   case ANetworkSession::kWhatData:
                 {
                     status_t err = onReceiveClientData(msg);  //调用消息处理函数

                     if (err != OK) {
                         mClient->onDisplayError(
                                 IRemoteDisplayClient::kDisplayErrorUnknown);
                     }
                     break;
                 }
           ...
 }

 status_t WifiDisplaySource::onReceiveClientData(const sp<AMessage> &msg) {

        ...
         if (method.startsWith("RTSP/")) {  //如果消息以"RTSP/"开头

         ResponseID id;
         id.mSessionID = sessionID;
         id.mCSeq = cseq;
         ssize_t index = mResponseHandlers.indexOfKey(id);
         ...
         HandleRTSPResponseFunc func = mResponseHandlers.valueAt(index);
         mResponseHandlers.removeItemsAt(index);

         status_t err = (this->*func)(sessionID, data);  //填充函数指针
          if (err != OK) {
             ALOGW("Response handler for session %d, cseq %d returned "
                   "err %d (%s)",
                   sessionID, cseq, err, strerror(-err));

             return err;
         }
           ...
         return OK;
     }
     status_t err;
     if (method == "OPTIONS") {
         err = onOptionsRequest(sessionID, cseq, data);   匹配处理方法类型
     } else if (method == "SETUP") {
         err = onSetupRequest(sessionID, cseq, data);
     } else if (method == "PLAY") {
         err = onPlayRequest(sessionID, cseq, data);
     } else if (method == "PAUSE") {
         err = onPauseRequest(sessionID, cseq, data);
     } else if (method == "TEARDOWN") {
         err = onTeardownRequest(sessionID, cseq, data);
     } else if (method == "GET_PARAMETER") {
         err = onGetParameterRequest(sessionID, cseq, data);
     } else if (method == "SET_PARAMETER") {
         err = onSetParameterRequest(sessionID, cseq, data);
     } else {
         sendErrorResponse(sessionID, "405 Method Not Allowed", cseq);

         err = ERROR_UNSUPPORTED;
     }

     return err;
 }

 首先，Source端接收函数类型为kWhatData的消息请求，会调用onReceiveClientData函数进行消息处理。该函数在获得发送信息的object对象、sessionID（此时的sessionID对应于clientSession）等信息后，根据object对象获取解析后的数据。由于此时消息以"RTSP/"开头，则会填充函数sendM1 中利用registerResponseHandler函数注册的函数指针onReceiveM1Response。如果回复信息中没有错误信息，即RTSP服务端返回的状态码为200,则表示RTSP服务端提供Sink端需要的那些RTSP方法。

与此同时，Sink端还会接下去执行，也就是调用sendM2函数，该函数如同sendM1函数，依旧是发送OPTIONS请求，只不过方向正好相反，是由Sink端发送Source端接收。具体流程与上面的流程一致，Source端在接收到OPTIONS请求请求后，会同样调用以下函数。

 status_t WifiDisplaySource::onOptionsRequest(
         int32_t sessionID,
         int32_t cseq,
         const sp<ParsedMessage> &data) {
     int32_t playbackSessionID;
     sp<PlaybackSession> playbackSession =
         findPlaybackSession(data, &playbackSessionID);

     if (playbackSession != NULL) {
         playbackSession->updateLiveness();
     }

     AString response = "RTSP/1.0 200 OK\r\n";
     AppendCommonResponse(&response, cseq);

     response.append(
             "Public: org.wfa.wfd1.0, SETUP, TEARDOWN, PLAY, PAUSE, "
             "GET_PARAMETER, SET_PARAMETER\r\n");

     response.append("\r\n");

     status_t err = mNetSession->sendRequest(sessionID, response.c_str());

     if (err == OK) {
         err = sendM3(sessionID);
     }

     return err;
 }

该函数会将Source端支持的所有方法通知给Sink端。同样的，Sink端也会填充类似的状态信息函数onReceiveM2Response。 如果回复信息中没有错误信息，即RTSP服务端返回的状态码为200,则表示RTSP服务端提供Source端需要的那些RTSP方法。

接下来，Source端会因为发送onOptionsRequest请求成功而继续调用sendM3函数以GET_PARAMETER方法发送获得Sink端所支持媒体流的内容保护（HDCP）支持性、视频格式信息、音频编码格式信息以及rtp客户端端口等信息的请求。Sink端则会调用onGetParameterRequest处理函数回复Sink端支持的相关信息。目前代码里可以看到Sink端并不支持内容保护特性。接下来，基本流程符合RTSP在进行媒体流通信的流程，这里就不做太多介绍。当流程调用到函数sendM5时，Source端会向Sink端发送SETUP命令，Sink端调用sendSetup启动sink端RTP线程，其中会利用createUDPSession创建UDP连接来传递音视频数据流。之后Source端会调用onSetupRequest函数做相应响应，如开启与编码Source端、打包相关的PlaybackSession线程，此过程算是Source端的核心代码，涉及到的内容较多如SurfaceFlinger等，希望有机会详细展开来介绍。当Setup流程结束后，Sink端通过sendPlay函数发送PLAY请求，Source端调用onPlayRequest函数做相应响应。如果playbackSession能够正常播放，则通过调用finishPlay函数完成开始播放的最后一些任务，如向Source端发送kWhatSessionEstablished消息，调用IRemoteDisplayClient的onDisplayConnected函数向应用层提供Wifi Display连接状态回调。

 mClient->onDisplayConnected(
                           mClientInfo.mPlaybackSession->getSurfaceTexture(),
                           mClientInfo.mPlaybackSession->width(),
                           mClientInfo.mPlaybackSession->height(),
                           mUsingHDCP
                               ? IRemoteDisplayClient::kDisplayFlagSecure
                               : 0);

该函数执行成功后，还会将Source状态由ABOUT_TO_PLAY改变为PLAYING。

当Sink端接收到Source端的数据流后，会调用/av/media/libstagefright/wifi-display/sink/RTPSink.cpp

下的parseRTP函数向TunnelRenderer类发送kWhatQueueBuffer消息，使其通过调用以下函数

/av/media/libstagefright/wifi-display/sink/TunnelRenderer.cpp

 mStreamSource->doSomeWork();

更新Sink端测试播放器PlayerClient在内存中的相关数据。具体流程放在下一回去做分析。

 原文在 http://blog.csdn.net/mznewfacer/article/details/8500102