《深入理解Android：Wi-Fi，NFC和GPS》章节连载[节选]--第二章 深入理解Netd
原文： http://blog.csdn.net/innost/article/details/20400389
本文使用的源碼版本為Android5.1
本章主要內容
介紹Netd;
介紹MDNS和Apple Bonjour技術;
介紹iptables、tc和ip等Linux系統中常用的網絡管理工具;
介紹Netd中的各個命令對象和相關的背景知識;
介紹NetworkManagmentService。
2.1 概述
Netd是Android系統中專門負責網絡管理和控制的后臺daemon程序，其功能主要分三大塊：
設置防火墻（Firewall）、網絡地址轉換（NAT）、帶寬控制、無線網卡軟接入點（Soft Access Point）控制，網絡設備綁定（Tether）等。
Android系統中DNS信息的緩存和管理。
網絡服務搜索（Net Service Discovery，簡稱NSD）功能，包括服務注冊（Service Registration）、服務搜索（Service Browse）和服務名解析（Service Resolve）等。
Netd的工作流程和Vold類似[1]，其工作可分成兩部分：
Netd接收并處理來自Framework層中NetworkManagementService或NsdService的命令。這些命令最終由Netd中對應的Command對象去處理。
Net接收并解析來自Kernel的UEvent消息，然后再轉發給Framework層中對應Service去處理。
由上述內容可知，Netd位于Framework層和Kernel層之間，它是Android系統中網絡相關消息和命令轉發及處理的中樞模塊。
Netd的代碼量不大，難度較低，但其所涉及的相關背景知識卻比較多。本章對Netd的分析將從以下幾個方面入手：
首先介紹Netd的大體工作流程以及DNS、MDns相關的背景知識。關于Netd的工作流程分析，讀者也可參考①中的內容。
然后本章將集中介紹Netd中涉及到的Android系統中網絡管理和控制的相關工具。它們是iptables、tc和ip。
最后將介紹Netd中CommandListener的命令處理。這些命令的正常工作依賴于上面介紹的iptables等工具。
最后，我們將介紹Java Framework中的NetworkManagementService服務。
提示：NsdService比較簡單，感興趣的讀者不妨閱讀作者的一篇博文”Android Says Bonjour”中的第2.2“NsdService介紹”一節。地址位于 http://blog.csdn.net/innost/article/details/8629139。
2.2 Netd工作流程分析
Netd進程由init進程根據init.rc的對應配置項[1]而啟動，其配置項為：
service netd /system/bin/netdclass mainsocket netd stream 0660 root systemsocket dnsproxyd stream 0660 root inetsocket mdns stream 0660 root system根據本章后續分析，讀者將會看到：
Framework層中的NetworkManagementService和NsdService將分別和"netd"及"mdns"監聽socket建立鏈接并交互。
每一個調用和域名解析相關的socket API（如getaddrinfo或gethostbyname等）的進程都會借由"dnsproxyd"監聽socket與netd建立鏈接。
下面開始分析Netd進程。
2.2.1 main函數分析
Netd進程的入口函數是其main函數，代碼如下所示：
system/netd/server/main.cpp
int main() {CommandListener *cl;NetlinkManager *nm;DnsProxyListener *dpl;MDnsSdListener *mdnsl;FwmarkServer* fwmarkServer;ALOGI("Netd 1.0 starting");remove_pid_file();blockSigpipe();//①創建NetlinkManagerif (!(nm = NetlinkManager::Instance())) {ALOGE("Unable to create NetlinkManager");exit(1);};//②創建CommandListener，它將創建名為"netd"的監聽socketcl = new CommandListener();nm->setBroadcaster((SocketListener *) cl);if (nm->start()) {ALOGE("Unable to start NetlinkManager (%s)", strerror(errno));exit(1);}// Set local DNS mode, to prevent bionic from proxying// back to this service, recursively.//注意下面這行代碼，它為本Netd設置環境變量ANDROID_DNS_MODE為"local"，其作用將在2.2.4節介紹setenv("ANDROID_DNS_MODE", "local", 1);//③創建DnsProxyListener，它將創建名為"dnsproxyd"的監聽socketdpl = new DnsProxyListener(CommandListener::sNetCtrl);if (dpl->startListener()) {ALOGE("Unable to start DnsProxyListener (%s)", strerror(errno));exit(1);}//④創建MDnsSdListener并啟動監聽，它將創建名為"mdns"的監聽socketmdnsl = new MDnsSdListener();if (mdnsl->startListener()) {ALOGE("Unable to start MDnsSdListener (%s)", strerror(errno));exit(1);}fwmarkServer = new FwmarkServer(CommandListener::sNetCtrl);if (fwmarkServer->startListener()) {ALOGE("Unable to start FwmarkServer (%s)", strerror(errno));exit(1);}/** Now that we're up, we can respond to commands*/if (cl->startListener()) {ALOGE("Unable to start CommandListener (%s)", strerror(errno));exit(1);}bool wrote_pid = write_pid_file();while(1) {sleep(30); // 30 secif (!wrote_pid) {wrote_pid = write_pid_file();}}ALOGI("Netd exiting");remove_pid_file();exit(0);
}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]
void NetlinkHandler::onEvent(NetlinkEvent *evt) {
const char *subsys = evt->getSubsystem();
......
//處理對應NETLINK_KOBJECT_UEVENT和NETLINK_ROUTE的信息
if (!strcmp(subsys, "net")) {
int action = evt->getAction();
const char *iface = evt->findParam("INTERFACE");//查找消息中攜帶的網絡設備名
if (action == evt->NlActionAdd) {
notifyInterfaceAdded(iface);//添加NIC（Network Interface Card）的消息
} else if (action == evt->NlActionRemove) {
notifyInterfaceRemoved(iface);//NIC被移除的消息
} else if (action == evt->NlActionChange) {
evt->dump();
notifyInterfaceChanged("nana", true);//NIC變化消息
} else if (action == evt->NlActionLinkUp) {//下面兩個消息來自NETLINK_ROUTE
notifyInterfaceLinkChanged(iface, true);//鏈路啟用（類似插網線）
} else if (action == evt->NlActionLinkDown) {
notifyInterfaceLinkChanged(iface, false);//鏈路斷開（類似拔網線）
}
} else if (!strcmp(subsys, "qlog")) {//對應NETLINK_NFLOG
const char *alertName = evt->findParam("ALERT_NAME");
const char *iface = evt->findParam("INTERFACE");
notifyQuotaLimitReached(alertName, iface);//當數據量超過預警值，則會收到該通知
} else if (!strcmp(subsys, "xt_idletimer")) {
//這個和后文的idletimer有關，用于跟蹤某個NIC的工作狀態，即是“idle”還是“active”
//檢測時間按秒計算
int action = evt->getAction();
const char *label = evt->findParam("LABEL");
const char *state = evt->findParam("STATE");
if (label == NULL) {
label = evt->findParam("INTERFACE");
}
if (state)
notifyInterfaceClassActivity(label, !strcmp("active", state));
}
......
}
由上邊代碼可知：
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。
提醒：請讀者結合上文所述流程自行研讀相關代碼。
[1]關于init工作原理以及init.rc的分析方法，讀者可參考《深入理解Android：卷1》第3章關于init進程的分析。
[1]讀者可參考《深入理解Android：卷1》第9章關于Vold的分析。
2.2.3 CommandListener分析
Netd中第二個重要成員是CommandListener（以后簡稱CL），其主要作用是接收來自Framework層NetworkManageService的命令。從角色來看，CL僅是一個Listener。它在收到命令后，只是將它們轉交給對應的命令處理對象去處理。CL內部定義了許多命令，而這些命令都有較深的背景知識。本節擬以分析CL的工作流程為主，而相關的命令處理則放到后文再集中分析。
CL中的圖2-4所示為CL中的Command對象及對應的Controller對象。
圖2-4 CL中的命令及控制類
由圖2-4可知：
CL定義了11個和網絡相關的Command類。這些類均從NetdCommand派生（注意，為保持繪圖簡潔，這11個Command的派生關系由1個派生箭頭表達）。
CL還定義了10個控制類，這些控制類將和命令類共同完成相應的命令處理工作。
結合前面圖2-2中對NM家族成員的介紹，CL創建時，需要注冊自己支持的命令類。這部分代碼在其構造函數中實現，代碼如下所示：
[-->CommandListener::CommandListener構造函數]
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();
//其他重要工作，后文再分析
}
由于CL的間接基類也是SocketListener，所以其工作流程和NetlinkHandler類似。
為了方便讀者理解，圖2-5給出了CL的工作流程圖：
圖2-5 CL的工作流程示意圖
圖2-5中，假設Client端發送的命令名是"nat"，當CL收到這個命令后，首先會從其構造函數中注冊的那些命令對象中找到對應該名字（即"nat"）的命令對象，其結果就是圖中的NatCmd對象。而該命令最終的處理工作將由此NatCmd對象的runCommand函數完成。
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的對應關系被稱之為一條記錄。客戶端一般會緩存這條記錄以備后續之用。
提醒：DNS解析規則比較復雜，感興趣的讀者可研究DNS的相關協議。
對軟件開發者來說，常用的域名解析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]
int getaddrinfo(const char *hostname, const char *servname,
const struct addrinfo *hints, struct addrinfo **res)
{
......//getaddrinfo的正常處理
//Android平臺的特殊定制
if (android_getaddrinfo_proxy(hostname, servname, hints, res) == 0) {
return 0;
}
......//如果上述函數處理失敗，則繼續getaddrinfo的正常處理
return error
}
由上述代碼可知，Android平臺中的getaddrinfo會調用其定制的android_getaddrinfo_proxy函數完成一些特殊操作，該函數的實現如下所示：
[-->getaddrinfo.c::android_getaddrinfo_proxy]
static int android_getaddrinfo_proxy(const char *hostname, const char *servname,
const struct addrinfo *hints, struct addrinfo **res)
{
.......
//取ANDROID_DNS_MODE環境變量。只有Netd進程設置了它
const char* cache_mode = getenv("ANDROID_DNS_MODE");
......
//由于Netd進程設置了此環境變量，故Netd進程調用getaddrinfo的話，將不會采用這套定制的方法
if (cache_mode != NULL && strcmp(cache_mode, "local") == 0) {
return -1;
}
//獲取本進程對應的DNS地址
snprintf(propname, sizeof(propname), "net.dns1.%d", getpid());
if (__system_property_get(propname, propvalue) > 0) {
return -1;
}
//建立和Netd中DnsProxyListener的連接，將請求轉發給它去執行
sock = socket(AF_UNIX, SOCK_STREAM, 0);
if (sock < 0) {
return -1;
}
......
strlcpy(proxy_addr.sun_path, "/dev/socket/dnsproxyd",
sizeof(proxy_addr.sun_path));
......//發送請求，處理回復等
return -1;
}
由上述代碼可知：
當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必須包含如下的頭文件和動態庫，并連接到：
#include <dns_sd.h> //必須包含此頭文件
libmdnssd.so //鏈接到此so
Bonjour中，服務注冊的API為DNSServiceRegister，原型如下：
DNSServiceErrorType DNSSD_API DNSServiceRegister
(
DNSServiceRef *sdRef,
DNSServiceFlags flags,
uint32_t interfaceIndex,
const char *name, /* may be NULL */
const char *regtype,
const char *domain, /* may be NULL */
const char *host, /* may be NULL */
uint16_t port, /* In network byte order */
uint16_t txtLen,
const void *txtRecord, /* may be NULL */
DNSServiceRegisterReply callBack, /* may be NULL */
void *context /* may be NULL */
);
該函數的解釋如下：
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，其原型如下：
DNSServiceErrorType DNSSD_API DNSServiceBrowse
(
DNSServiceRef *sdRef,
DNSServiceFlags flags,
uint32_t interfaceIndex,
const char *regtype,
const char *domain, /* may be NULL */
DNSServiceBrowseReply callBack,
void *context /* may be NULL */
);
其中：
sdref、interfaceIndex、regtype、domain以及context含義與DNSServiceRegister一樣。
flags：在本函數中沒有作用。
callBack：為DNSServiceBrowser處理結果的回調通知接口。
當客戶端想獲得指定服務的IP和端口號時，需要使用DNSServiceResolve API，其原型如下：
DNSServiceErrorType DNSSD_API DNSServiceResolve
(
DNSServiceRef *sdRef,
DNSServiceFlags flags,
uint32_t interfaceIndex,
const char *name,
const char *regtype,
const char *domain,
DNSServiceResolveReply callBack,
void *context /* may be NULL */
);
其中：
name、regtype和domain都從DNSServiceBrowse函數的處理結果中獲得。
callBack用于通知DNSServiceResolve的處理結果。該回調函數將返回服務的IP地址和端口號。
2. MDnsSdListener分析
MDnsSdListener對應的Framework層服務為NsdService（Nsd為Network Service Discovery的縮寫），它是Android 4.1新增的一個Framework層Service。該服務的實現比較簡單，故本書不擬詳細討論它。感興趣的讀者不妨首先閱讀SDK中關于NsdService的相關文檔。
提示：SDK中有一個基于Nsd技術開發的NsdChat例程，讀者也可先學習它的實現。相關文檔位置為http://developer.android.com/training/connect-devices-wirelessly/nsd.html。
圖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]
MDnsSdListener::Monitor::Monitor() {
mHead = NULL;
pthread_mutex_init(&mHeadMutex, NULL);
//創建兩個socket，用于接收MDnsSdListener對象的指令
socketpair(AF_LOCAL, SOCK_STREAM, 0, mCtrlSocketPair);
//創建線程，線程函數是threadStart，其內部會調用run
pthread_create(&mThread, NULL, MDnsSdListener::Monitor::threadStart, this);
}
Monitor的threadStart線程將調用其run函數，該函數通過poll方式偵聽包括mCtrlSocketPair在內的socket信息。這部分代碼屬于基本的Linux socket編程，本書不擬開展深入討論。
當NsdService發送"start-service"命令后，Handler的runCommand將執行Monitor的startService函數，代碼如下所示：
[-->MDnsSdListener.cpp::Monitor:startService]
int MDnsSdListener::Monitor::startService() {
int result = 0;
char property_value[PROPERTY_VALUE_MAX];
pthread_mutex_lock(&mHeadMutex);
//MDNS_SERVICE_STATUS是一個字符串，值為“init.svc.mdnsd”，在init.rc配置文件中，mdnsd是一個
//service，而“init.svc.mdnsd”將記錄mdnsd進程的運行狀態。
property_get(MDNS_SERVICE_STATUS, property_value, "");
if (strcmp("running", property_value) != 0) {
//如果mdnsd的狀態不為"running"，則通過設置“ctl.start”命令啟動mdnsd
property_set("ctl.start", MDNS_SERVICE_NAME);
//如果mdnsd成功啟動，則屬性值變成"running"
wait_for_property(MDNS_SERVICE_STATUS, "running", 5);
result = -1;
} else {
result = 0;
}
pthread_mutex_unlock(&mHeadMutex);
return result;
}
startService的實現比較有趣，它充分利用了init的屬性控制以啟動mdnsd進程。
當NsdService發送注冊服務請求時，Handler的serviceRegister函數將被調用，代碼如下所示：
[-->MDnsSdListener.cpp::Handler:serviceRegister]
void MDnsSdListener::Handler::serviceRegister(SocketClient *cli, int requestId,
const char *interfaceName, const char *serviceName, const char *serviceType,
const char *domain, const char *host, int port, int txtLen, void *txtRecord) {
Context *context = new Context(requestId, mListener);
DNSServiceRef *ref = mMonitor->allocateServiceRef(requestId, context);
port = htons(port);
......
DNSServiceFlags nativeFlags = 0;
int interfaceInt = ifaceNameToI(interfaceName);
//調用Bonjour API DNSServiceRegister，并注冊回調函數MDnsSdListenerRegisterCallback
DNSServiceErrorType result = DNSServiceRegister(ref, interfaceInt,
nativeFlags, serviceName, serviceType, domain, host, port,
txtLen, txtRecord, &MDnsSdListenerRegisterCallback, context);
if (result != kDNSServiceErr_NoError) {
.....//錯誤處理
}
//通知Monitor對象進行rescan，請讀者自行研究該函數
mMonitor->startMonitoring(requestId);
cli->sendMsg(ResponseCode::CommandOkay, "serviceRegister started", false);
return;
}
DNSServiceRegister內部將把請求發送給mdnsd去處理，處理的結果通過MDnsSdListenerRegisterCallback返回，該函數代碼如下所示：
[-->MDnsSdListener.cpp::MDnsSdListenerRegisterCallback]
void MDnsSdListenerRegisterCallback(DNSServiceRef sdRef, DNSServiceFlags flags,
DNSServiceErrorType errorCode, const char *serviceName, const char *regType,
const char *domain, void *inContext) {
MDnsSdListener::Context *context =
einterpret_cast<MDnsSdListener::Context *>(inContext);
char *msg;
int refNumber = context->mRefNumber;
if (errorCode != kDNSServiceErr_NoError) {
......//錯誤處理
} else {
char *quotedServiceName = SocketClient::quoteArg(serviceName);
asprintf(&msg, "%d %s", refNumber, quotedServiceName);
free(quotedServiceName);
//將處理結果返回給NsdService
context->mListener->sendBroadcast(ResponseCode::ServiceRegistrationSucceeded,
msg,false);
}
free(msg);
}
提示 本節對Netd的工作流程進行了相關分析，這部分代碼相對簡單，處理流程也比較固定：
1）NM接收Kernel的UEvent消息，然后轉發給Framework層的客戶端。
2）CL、DPL以及MDnsSdListener接收來自客戶端的請求并處理它們。
唯一有趣的地方是Android中DNS的管理以及Apple Bonjour技術。感興趣的讀者不妨閱讀本章列出的參考資料以加深理解。
[1]此處結論來自bionic/libc/docs/OVERVIEW.txt文件，不過根據同目錄下CHANGES.txt的說明，resolv.conf將不再使用
====================================================================================
=========================略略略略略略略略略略略略略略==================================
2.5 本章總結和參考資料說明
2.5.1 本章總結
本章對Netd進行了詳細討論。相信讀者讀完此章的第一感受一定是代碼這么容易的模塊，竟然涉及如此多復雜的背景知識。確實，這也是專題卷所述內容的核心特點。從代碼上看也許它們并不復雜，但是其背后的理論知識卻可能大有來頭。對于這些內容而言，代碼只是外在的表現形式，其核心一定在其背后的那些知識中。所以，讀者在閱讀專題卷的時候，一定要考察自己是否對背景知識有所掌握。
概況而言，Netd涉及的內容和網絡管理與控制有關，例如DNS、Apple Bonjour、利用iptables等工具實現NAT、防火墻、帶寬控制、流量控制、路由控制功能，以及USB綁定Wi-Fi、SoftAP等。請讀者在本節的參考資料一覽中找到并繼續研究自己感興趣的內容。
最后，我們對NetworkManagementService進行了介紹。NMService的內容非常簡單。
2.5.2 參考資料說明
Linux PF_NETLINK相關資料
[1] Linux man PF_NETLINK
本文檔是Linux系統中的幫助文檔。從總體上介紹了PF_NETLINK（AF_NETLINK）的作用和相關的數據結構。對熟手比較適用。
[2] http://www.linuxjournal.com/article/8498
“Manipulating the Networking Environment Using RTNETLINK”，這篇文章以RTNETLINK為主要對象，介紹了如何利用它進行編程以操作網絡。此文寫得非常詳細，建議讀者深入閱讀，甚至自己動手寫測試例子。
DNS、Apple Bonjour相關資料
[3] http://baike.baidu.com/view/22276.htm
百度百科中關于dns的介紹，屬于入門級材料，不清楚的讀者可以先了解相關知識。
[4] http://en.wikipedia.org/wiki/MDNS
維基百科中關于Multicast DNS的介紹。入門級材料，但包含的信息不是很全，需要跟蹤其中的鏈接才能對MDNS有全面了解。
[5] https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NetServices/Introduction.html#//apple_ref/doc/uid/TP40002445-SW1
“Introduction to Bonjour Overview”，蘋果開發網站上關于Bonjour基礎知識的入口，包含“About Bonjour”、“Bonjour API Architecture”等文檔。
[6] https://developer.apple.com/library/mac/#documentation/Networking/Conceptual/dns_discovery_api/Introduction.html#//apple_ref/doc/uid/TP30000964
“DNS Service Discovery Programming Guide”，蘋果開發網站關于NSD API的說明。
iptables相關資料
iptables的相關文檔非常多，雖然Linux也提供了幫助文檔（man iptables），但對新手來說該文檔實在不是學習的好資料。
[7] http://www.thegeekstuff.com/2011/01/iptables-fundamentals/
“Linux Firewall Tutorial: IPTables Tables, Chains, Rules Fundamentals”，這篇文章首先從原理上介紹了如何去理解iptables，然后介紹了相關的例子。筆者認為它是iptables最好的入門資料。
[8] http://selboo.com.cn/post/721/
“iptables的相關概念和數據包的流程”，這篇文檔介紹了iptables中各個table及chain的處理順序，請讀者結合[7]來理解iptables。
[9] http://www.frozentux.net/iptables-tutorial/cn/iptables-tutorial-cn-1.1.19.html
“Iptables 指南 1.1.19”，這篇文檔介紹的iptables版本比較舊（Android 4.2使用的iptables版本是1.4.11），但對iptables常用參數都有非常詳細的介紹。適合入門后的讀者進行深入閱讀。
TC相關資料
tc文獻的數量和難度遠大于iptables，此處精選幾個必讀文獻。
[10] http://linux-ip.net/articles/Traffic-Control-HOWTO/intro.html
“Traffic Control HOWTO”，理解traffic control的必讀文獻，覆蓋面很全，理論知識講解到位。難度稍大，需要仔細琢磨才能完全理解。
[11] http://wenku.baidu.com/view/f02078db50e2524de5187e45.html
“TC(Linux下流量控制工具)詳細說明及應用實例”，百度文庫中的一篇文檔，篇幅雖然不長，但也做到了理論和實例結合。建議讀者先閱讀此文獻，然后再深入研究[10]。
[12] http://fanqiang.chinaunix.net/a1/b1/20010811/0705001103.html
“在LINUX中實現流量控制器”，介紹TC的一篇博文，主要對tc的命令用法列舉了不少實例，屬于tc的實戰文章。建議放到最后閱讀。
[13] http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb
這是筆者能找到的關于IFB設備最完整的資料，對IFB的使用、常規用法等進行了全方位的介紹。
IP命令相關資料
ip命令比較簡單，這里僅給出一篇文獻。
[14] http://blog.chinaunix.net/uid-24921475-id-2547198.html
Linux ip命令介紹
NetDevice編程文獻
[15] Linux man netdevice
非常詳細的NetDevice編程介紹，建議讀者認真閱讀。
Linux策略路由相關資料
[16] http://www.cnblogs.com/iceocean/articles/1594488.html
“Linux策略路由”，中文文檔，知識面覆蓋較全，屬于入門級資料。
[17] http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html
“Policy Routing With Linux”，這是一本完整的書籍（可見網管是一個復雜的工作）。個人感覺[16]是參考[17]的學習總結。屬于高級閱讀材料，難度較大。
Linux IPv6控制相關資料
[18] http://www.ipsidixit.net/2012/08/09/ipv6-temporary-addresses-and-privacy-extensions/
“IPv6 temporary addresses and privacy extensions”，介紹Linux中IPv6臨時地址和privacy extensions方面的知識，知識覆蓋面較全。屬于入門資料。
TTY和ptmx編程相關資料
[19] http://tldp.org/HOWTO/Text-Terminal-HOWTO.html
“Text-Terminal-HOWTO”，比較舊的資料，覆蓋面非常廣。讀者可僅閱讀自己想了解的章節。
[20] http://blog.tianya.cn/blogger/post_read.asp?BlogID=3616841&PostID=33399981
“Linux下tty/pty/pts/ptmx 詳解”，中文寫的好材料，還列出了其參考的文獻。最后，關于ptmx，讀者還可通過man ptmx獲得如何用它進行編程的指導。
PPP和Pppd相關資料
[21] http://tldp.org/HOWTO/PPP-HOWTO/
“Linux PPP HOWTO”，Linux HowTo系列的內容都簡單易懂。雖章節較多，但很多內容僅一兩句了事。可做入門參考。
[22] http://network.51cto.com/art/201009/223784.htm
“基礎解讀PPP協議”，中文文檔，一頁內容，主要介紹PPP框架性的內容。
[23] http://wenku.baidu.com/view/0c395f15866fb84ae45c8d4a.html
“ppp介紹”，百度文庫中的一個關于ppp的PPT。內容翔實，不僅介紹了ppp協議的數據包，也從框架上介紹了ppp的工作流程。建議讀者首先閱讀此文獻。
[24] Linux man pppd
介紹pppd中各個選項的作用。
NAT相關資料
[25] http://oa.jmu.edu.cn/netoa/libq/pubdisc.nsf/66175841be38919248256e35005f4497/7762e8e1056be98f48256e88001ef71d?OpenDocument
“用iptables實現NAT”，中文文檔，簡單易懂。
Tether、RNDIS、DHCP、DNSmasq相關資料
[26] http://en.wikipedia.org/wiki/Tethering
“Tethering”，維基百科中關于Tether的介紹，淺顯易懂，屬于普及型資料。
[27] http://msdn.microsoft.com/en-us/library/windows/hardware/gg463293.aspx
“Remote NDIS (RNDIS) and Windows”，MSDN文檔，非常翔實（不得不說微軟在文檔方面的工作真的是一絲不茍）。
[28] http://baike.baidu.com/view/7992.htm?subLemmaId=7992&fromenter=%A3%C4%A3%C8%A3%C3%A3%D0
百度百科中關于DHCP的解釋，入門資料。
[29] http://baike.baidu.com/view/6681631.htm
百度百科中關于DNSmasq的解釋。
[30] http://wenku.baidu.com/view/662b536b561252d380eb6ec1.html
關于DHCP協議中option字段的詳細介紹。
Softap和hostapd相關資料
[31] 《802.11 無線網絡權威指南中文第二版》
讀者可先閱讀第1、2章中關于Wi-Fi技術中的一些基本概念，例如AP和Station。
[32] http://baike.baidu.com/view/2475889.htm
百度百科關于SoftAp的入門級介紹。
[33] 關于hostapd，讀者可利用man hostapd得到各個選項的用法。
提示，讀者必須先安裝hostapd，然后才能查閱其幫助文檔。
總結
以上是生活随笔為你收集整理的《深入理解Android：Wi-Fi，NFC和GPS》章节连载[节选]--第二章 深入理解Netd的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux那些事儿 之 戏说USB(大结
- 下一篇： WifiP2pSettings工作流程