《深入理解Android：Wi-Fi，NFC和GPS》章节连载[节选]--第二章 深入理解Netd

提示：NsdService比较简单，感兴趣的读者不妨阅读作者的一篇博文”Android Says Bonjour”中的第2.2“NsdService介绍”一节。地址位于http://blog.csdn.net/innost/article/details/8629139。

Netd进程由init进程根据init.rc的对应配置项[1]而启动，其配置项如图2-1所示。

图2-1  Netd启动配置参数

由图2-1可知：

• Netd启动时将创建三个TCP监听socket，其名称分别为"netd"，"dnsproxyd"和"mdns"。

根据本章后续分析，读者将会看到：

• Framework层中的NetworkManagementService和NsdService将分别和"netd"及"mdns"监听socket建立链接并交互。
• 每一个调用和域名解析相关的socket API（如getaddrinfo或gethostbyname等）的进程都会借由"dnsproxyd"监听socket与netd建立链接。

下面开始分析Netd进程。

2.2.1  main函数分析

Netd进程的入口函数是其main函数，代码如下所示：

[-->main.cpp]

Netd的main函数非常简单，主要是创建几个重要成员并启动相应的工作，这几个重要成员分别是：

• NetlinkManager：它将接收并处理来自Kernel的UEvent消息。这些消息经NetlinkManager解析后将借助它的Broadcaster（也就是代码中为NetlinkManager设置的CommandListener）发送给Framework层的NetworkManagementService。
• CommandListener、DnsProxyListener、MDnsSdListener：分别创建名为"netd"、"dnsproxyd"、"mdns"的监听socket，并处理来客户端的命令。

下面将分别讨论这四位成员的作用。

2.2.2  NetlinkManager分析

NetlinkManager（以后简称NM）主要负责接收并解析来自Kernel的UEvent消息。其核心代码在start函数中，如下所示。

 [-->NetlinkManager.cpp::start]

NM的start函数主要是向Kernel注册了三个用于接收UEvent事件的socket，这三个UEvent[1][2]分别对应于：

• NETLINK_KOBJECT_UEVENT：代表kobject事件，由于这些事件包含的信息由ASCII字符串表达，故上述代码中使用了NETLINK_FOMRAT_ASCII。它表示将采用字符串解析的方法去解析接收到的UEvent消息。kobject一般用来通知内核中某个模块的加载或卸载。对NM来说，其关注的是/sys/class/net下相应模块的加载或卸载消息。
• NETLINK_ROUTE：代表kernel中routing或link改变时对应的消息。NETLINK_ROUTE包含很多子项，上述代码中使用了RTMGRP_LINK项。二者结合起来使用，表示NM希望收到网络链路断开或接通时对应的UEvent消息（笔者在Ubuntu PC机上测试过，当网卡上拔掉或插入网线时，会触发这些UEvent消息的发送）。由于对应UEvent消息内部封装了nlmsghdr等相关结构体，故上述代码使用了NETLINK_FORMAT_BINARY来指示解析UEvent消息时将使用二进制的解析方法。
• NETLINK_NFLOG：和2.3.6节介绍的带宽控制有关。Netd中的带宽控制可以设置一个预警值，当网络数据超过一定字节数就会触发kernel发送一个警告。该功能属于iptables的扩展项，但由于iptables的文档更新速度较慢（这也是很多开源项目的一大弊端），笔者一直未能找到相关的正式说明。值得指出的是，上述代码中有关NETLINK_NFLOG相关socket的设置并非所有kernel版本都支持。同时，NFLOG_QUOTA_GROUP的值是直接定义在NetlinkManager.cpp中的，而非和其他类似系统定义一样定义在系统头文件中。这也表明NFLOG_QUOTA_GROUP的功能比较新。

提示：读者可通过在Linux终端中执行man PF_LINK得到有关NETLINK的详细说明。

上述start函数将调用setupSocket创建用于接收UEvent消息的socket以及一个解析对象NetlinkHandler。setupSocket代码本身比较简单，此处就不拟展开分析。

下面来看NM及其家族成员，它们之间的关系如图2-2所示。

图2-2  NetlinkManager家族成员的类图

由图2-2可知：

• NetlinkHandler和CommandListener均间接从SocketListener派生。其中，NetlinkHandler收到的socket消息将通过onEvent回调处理。
• 结合前文所述，NetlinkManager分别注册了三个用于接收UEvent的socket，其对应的NetlinkHandler分别是mUeventHandler、mRouteHandler和mQuotaHandler。
• NetlinkHandler接收到的UEvent消息会转换成一个NetlinkEvent对象。NetlinkEvent对象封装了对UEvent消息的解析方法。对于NETLINK_FOMRAT_ASCII类型，其parseAsciiNetlinkMessage函数会被调用，而对于NETLINK_FORMAT_BINARY类型，其parseBinaryNetlinkMessage函数会被调用。
• NM处理流程的输入为一个解析后的NetlinkEvent对象。NM完成相应工作后，其处理结果将经由mBroadcaster对象传递给Framework层的接收者，也就是NetworkManagementService。
• CommandListener从FrameworkListener派生，而FrameworkListener内部有一个mCommands数组，它用来存储注册到FrameworkListener中的命令处理对象。

下面来简单了解下NetlinkHandler的onEvent函数，由于其内部已针对不同属性的NetlinkEvent进行了分类处理，故浏览这段代码能加深对前文所述不同UEvent消息的作用的理解。

[-->NetlinkHandler.cpp::onEvent]

由上边代码可知：

• NETLINK_KOBJECT_UEVENT和NETLINK_ROUTE主要反映网络设备的事件和状态，包括NIC的添加、删除和修改，以及链路的连接状态等。
• NETLINK_NFLOG用于反映设置的log是否超过配额。
• 另外，上边代码中还处理了“xt_idletimer”的uevent消息，它和后文要介绍的IdleTimerCmd有关，主要用来监视网络设备的收发工作状态。当对应设备工作或空闲时间超过设置的监控时间后，Kernel将会发送携带其状态（"idle"或"active"）的UEvent消息。

图2-3所示为NetlinkHandler的工作流程。

图2-3  NM工作流程图

由图2-3可知：

• NM创建NetlinkHandler后，工作便转交给NetlinkHandler来完成，而每个NetlinkHandler对象均会单独创建一个线程用于接收Socket消息。
• 当Kernel发送UEvent消息后，NetlinkHandler便从select调用中返回，然后调用其onDataAvailable函数，该函数内部会创建一个NetlinkEvent对象。
• NetlinkEvent对象根据socket创建时指定的解析类型去解析来自Kernel的UEvent消息。
• 最终NetlinkHandler的onEvent将被调用，不同的UEvent消息将在此函数中进行分类处理。
• NetlinkHandler最终将处理结果经由NM内部变量mBroadcaster转发给NetworkManagementService。

CommandListener::CommandListener() :

                 FrameworkListener("netd", true) {

    registerCmd(new InterfaceCmd());//注册11个命令类对象

    registerCmd(new IpFwdCmd());

    registerCmd(new TetherCmd());

    registerCmd(new NatCmd());

    registerCmd(new ListTtysCmd());

    registerCmd(new PppdCmd());

    registerCmd(new SoftapCmd());

    registerCmd(new BandwidthControlCmd());

    registerCmd(new IdletimerControlCmd());

    registerCmd(new ResolverCmd());

    registerCmd(new FirewallCmd());

    //创建对应的控制类对象

    if (!sSecondaryTableCtrl)

        sSecondaryTableCtrl = new SecondaryTableController();

    if (!sTetherCtrl)

        sTetherCtrl = new TetherController();

    if (!sNatCtrl)

        sNatCtrl = new NatController(sSecondaryTableCtrl);

    if (!sPppCtrl)

        sPppCtrl = new PppController();

    if (!sSoftapCtrl)

        sSoftapCtrl = new SoftapController();

    if (!sBandwidthCtrl)

        sBandwidthCtrl = new BandwidthController();

    if (!sIdletimerCtrl)

        sIdletimerCtrl = new IdletimerController();

    if (!sResolverCtrl)

        sResolverCtrl = new ResolverController();

    if (!sFirewallCtrl)

        sFirewallCtrl = new FirewallController();

    if (!sInterfaceCtrl)

        sInterfaceCtrl = new InterfaceController();

    //其他重要工作，后文再分析

2.2.4 DnsProxyListener分析

DnsProxyListener和Android系统中的DNS管理有关。什么是DNS呢？Android系统中DNS又有什么特点呢？来看下文。

1. Android DNS介绍[3]

DNS是Domain Name System（域名系统）的缩写。其主要目的是在域名和IP地址之间建立一种映射。简单点说，DNS的功能类似于电话簿，它可将人名映射到相应的电话号码。在DNS中，人名就是域名，电话号码就是IP地址。域名系统的管理由DNS服务器来完成。全球范围内的DNS服务器共同构成了一个分布式的域名-IP数据库。

对使用域名来发起网络操作的网络程序来说，其域名解析工作主要分两步：

1）第一步工作就是需要将域名转换成IP。由于域名和IP的转换关系存储在DNS服务器上，所以该网络程序要向DNS服务器发起请求，以获取域名对应的IP地址。

2）DNS服务器根据DNS解析规则解析并得到该域名对应的IP地址，然后返回给客户端。在DNS中，每一个域名和IP的对应关系被称之为一条记录。客户端一般会缓存这条记录以备后续之用。

对软件开发者来说，常用的域名解析socket API有两个：

• getaddrinfo：它根据指定的host名或service名得到对应的IP地址（该IP地址由结构体addrinfo表达）。
• getnameinfo：根据指定的IP地址（由结构体sockaddr表达）得到对应的host或service的名称。

Android中，这两个函数均由Bionic C实现。其代码实现基于NetBSD的解析库（resolver library），并经过一些修改。这些修改包括：

• 没有实现name-server-switch功能。这是为了保持Bionic C库的轻便性而做的裁剪。
• DNS服务器的配置文件由/etc/resolv.conf变成/system/etc/resolv.conf[1]。在Android系统中，/etc目录实际上为/system/etc目录的链接。resolv.conf存储的是DNS服务器的IP地址。
• 系统属性中保存了一些DNS服务器的地址，它们通过诸如"net.dns1"或"net.dns2"之类的属性来表达。这些属性由dhcpd进程或其他系统模块负责维护。
• 每个进程还可以设置进程特定的DNS服务器地址。它们通过诸如"net.dns1.<pid>"或"net.dns2.<pid>"的系统属性来表达。
• 不同的网络设备也有对应的DNS服务器地址，例如通过wlan接口发起的网络操作，其对应的DNS服务器由系统属性“net.wlan.dns1”表示。

图2-6所示为三星Galaxy Note2中有关dns信息的示意图。

图2-6  net.dns设置示意图

由图2-6可知：

• 系统中有些进程有自己特定的DNS服务器。
• 不同网络设备也设置了对应的DNS服务器地址。

2. getaddrinfo函数分析

本节将介绍Android中getaddrinfo的实现，我们将只关注Android对其做的改动。

[-->getaddrinfo.c::getaddrinfo]

由上述代码可知，Android平台中的getaddrinfo会调用其定制的android_getaddrinfo_proxy函数完成一些特殊操作，该函数的实现如下所示：

[-->getaddrinfo.c::android_getaddrinfo_proxy]

由上述代码可知：

• 当Netd进程调用getaddrinfo时，由于其设置了ANDROID_DNS_MODE环境变量，所以该函数会继续原来的流程。
• 当非Netd进程调用getaddrinfo函数时，首先会开展android_getaddrinfo_proxy中的工作，即判断该进程是否有定制的DNS服务器，如果没有的话它将和位于Netd进程中的"dnsproxyd"监听socket建立连接，然后把请求发给DnsProxyListener去执行。

3. DnsProxyListener命令介绍

下面来介绍DnsProxyListener（以后简称DPL），图2-7所示为其家族成员示意图：

图2-7  DPL家族示意图

由图2-7可知，DPL仅定义了两个命令：

• GetAddrInfoCmd，和Bionic C库的getaddrinfo函数对应。
• GetHostByAddrCmd，和Bionic C库的gethostbyaddr函数对应。

这个两条命令的处理比较简单，此处就不拟展开详细的代码。

为方便读者理解，我们将给出调用序列图，如图2-8所示。

图2-8  GetAddrInfoCmd处理流程示意图

由图2-8所示，GetAddrInfoHandler最终的处理还是交由Bionic C的getaddrinfo函数来完成。根据前文所述，由于Netd进程设置了ANDROID_DNS_MODE环境变量，故Netd调用的getaddrinfo将走正常的流程。这个正常流程就是Netd进程将向指定的DNS服务器发起请求以解析域名。

Android系统中，通过这种方式来管理DNS的好处是所有解析后得到的DNS记录都将缓存在Netd进程中，从而使这些信息成为了一个公共的资源，最大程度内做到了信息共享。

2.2.5 MDnsSdListener分析

MDnsSd是Multicast DNS Service Discovery的简称，它和Apple公司的Bonjour技术有关，故本节将先介绍Apple Bonjour技术。

1. Apple Bonjour技术介绍[4][5][6]

Bonjour是法语中的Hello之意。它是Apple公司为基于组播域名服务(multicast DNS)的开放性零配置网络标准所起的名字。使用Bonjour的设备在网络中自动组播它们自己的服务信息并监听其他设备的服务信息，设备之间就像在打招呼，这也是该技术命名为Bonjour的原因。Bonjour使得局域网中的系统和服务即使在没有网络管理员的情况下也很容易被找到。

举一个简单的例子：在局域网中，如果要进行打印服务，就必须先知道打印服务器的IP地址。此IP地址一般由IT部门的人负责分配，然后他还得全员发邮件以公示此地址。有了Bonjour以后，打印服务器自己会依据零配置网络标准在局域网内部找到一个可用的IP并注册一个打印服务，名为“print service”之类的。当客户端需要打印服务时，会先搜索网络内部的打印服务器。由于不知道打印服务器的IP地址，客户端只能根据诸如"print service"的名字去查找打印机。在Bonjour的帮助下，客户端最终能找到这台注册了“print service”名字的打印机，并获得它的IP地址以及端口号。

从Bonjour角度来看，该技术主要解决了三个问题：

• Addressing：即为主机分配IP。Bonjour的Addressing处理比较简单，即每个主机在网络内部的地址可选范围内找一个IP，然后查看下网络内部是否有其他主机再用。如果该IP没有被分配的话，它将使用此IP。
• Naming：Naming解决的就是host和IP地址的对应关系。Bonjour采用的是Multiple DNS技术，即DNS查询消息将通过UDP组播方式发送。一旦网络内部某个机器发现查询的机器名和自己设置的一样，就回复这条请求。此外，Bonjour还拓展了MDNS的用途，即除了能查找host外，还支持对service的查找。不过，Bonjour的Naming有一个限制，即网络内部不能有重名的host或service。
• Service Discovery：SD基于上面的Naming工作，它使得应用程序能查找到网络内部的服务，并解析该服务对应的IP地址和端口号。应用程序一旦得到服务的IP地址和端口号，就可以直接和该服务建立交互关系。

Bonjour技术在Mac OS以及Itunes、Iphone上都得到了广泛应用。为了进一步推广，Apple通过开源工程mdnsresponder将其开源出来。在Windows平台上，它将生成一个后台程序mdnsresponder。在Android平台上（或者说支持POSIX的Linux平台）它是一个名为mdnsd的程序。不过，不论是mdnsresponder还是mdnsd，应用开发者要做的仅仅是利用Bonjour的API向它们发起服务注册、服务查询和服务解析等请求并接收来自它们的处理结果。

下面我们将介绍Bonjour API中使用最多的三个函数，它们分别是服务注册、服务查询和服务解析。理解这三个函数的功能也是理解MDnsSdListener的基础。

使用Bonjour API必须包含如下的头文件和动态库，并连接到：

Bonjour中，服务注册的API为DNSServiceRegister，原型如下：

该函数的解释如下：

• sdRef：代表一个未初始化的DNSService实体。其类型DNSServiceRef是指针。该参数最终由DNSServiceRegister函数分配内存并初始化。
• flags：表示当网络内部有重名服务时的冲突处理。默认是按顺序修改服务名。例如要注册的服务名为“printer”，当检测到重名冲突时，就可改名为“printer(1)”。
• interfaceIndex：表示该服务输出到主机的哪些网络接口上。值-1表示仅对本机支持，也就是该服务的用在loop接口上。
• name：表示服务名，为空的话就取机器名。
• regtype：服务类型，用字符串表达。Bonjour要求格式为"_服务名._传输协议"，例如"_ftp._tcp"。目前传输协议仅支持TCP和UDP。
• domian和host一般都为空。
• port表示该服务的端口。如果为0的话，Bonjour会自动分配一个。
• txtLen以及txtRecord字符串用来描述该服务。一般都设置为空。
• callBack：设置回调函数。该服务注册的请求结果都会通过它回调给客户端。
• context：上下文指针，由应用程序设置。

当客户端需要搜索网络内部特定服务时，需要使用DNSServiceBrowser API，其原型如下：

• sdref、interfaceIndex、regtype、domain以及context含义与DNSServiceRegister一样。
• flags：在本函数中没有作用。
• callBack：为DNSServiceBrowser处理结果的回调通知接口。

当客户端想获得指定服务的IP和端口号时，需要使用DNSServiceResolve API，其原型如下：

• name、regtype和domain都从DNSServiceBrowse函数的处理结果中获得。
• callBack用于通知DNSServiceResolve的处理结果。该回调函数将返回服务的IP地址和端口号。

2. MDnsSdListener分析

MDnsSdListener对应的Framework层服务为NsdService（Nsd为Network Service Discovery的缩写），它是Android 4.1新增的一个Framework层Service。该服务的实现比较简单，故本书不拟详细讨论它。感兴趣的读者不妨首先阅读SDK中关于NsdService的相关文档。

图2-9所示为MDnsSdListener的家族成员示意图。

图2-9  MDnsSdListener家族成员

由图2-9可知：

• MDnsSdListener的内部类Monitor用于和mdnsd后台进程通信，它将调用前面提到的Bonjour API。
• Monitor内部针对每个DNSService都会建立一个Element对象，该对象通过Monitor的mHead指针保存在一个list中。
• Handler是MDnsSdListener注册的Command。

下面将简单介绍MDnsSdListener的运行过程，主要工作可分成三步：

1）Netd创建MDnsSdListener对象，其内部会创建Monitor对象，而Monitor对象将启动一个线程用于和mdnsd通信，并接收来自Handler的请求。

2）NsdService启动完毕后将向MDnsSdListener发送"start-service"命令。

3）NsdService响应应用程序的请求，向MDnsSdListener发送其他命令，例如"discovery"等。Monitor将最终处理这些请求。

先来看第一步，当MDnsSdListener构造时，会创建一个Monitor对象，代码如下所示：

[-->MDnsSdListener.cpp::Monitor:Monitor]

Monitor的threadStart线程将调用其run函数，该函数通过poll方式侦听包括mCtrlSocketPair在内的socket信息。这部分代码属于基本的Linux socket编程，本书不拟开展深入讨论。

当NsdService发送"start-service"命令后，Handler的runCommand将执行Monitor的startService函数，代码如下所示：

[-->MDnsSdListener.cpp::Monitor:startService]

startService的实现比较有趣，它充分利用了init的属性控制以启动mdnsd进程。

当NsdService发送注册服务请求时，Handler的serviceRegister函数将被调用，代码如下所示：

[-->MDnsSdListener.cpp::Handler:serviceRegister]

DNSServiceRegister内部将把请求发送给mdnsd去处理，处理的结果通过MDnsSdListenerRegisterCallback返回，该函数代码如下所示：

[-->MDnsSdListener.cpp::MDnsSdListenerRegisterCallback]