[置顶] 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在内存中的相关数据。具体流程放在下一回去做分析。