《深刻理解Android：Wi-Fi，NFC和GPS》章節連載[節選]--第二章深刻理解Netd

時間 2019-12-13

標籤深刻理解 android nfc gps 章節連載節選第二 netd 欄目 Android 简体版

原文原文鏈接

首先感謝各位兄弟姐妹們的耐心等待。本書預計在3月中旬上市發售。從今天開始，我將在博客中連載此書的一些內容。注意，此處連載的是未經出版社編輯的原始稿件，因此樣子會有些非專業。html

注意，以下是本章目錄，本文節選2.1-2.3以及2.5節。linux

爲了方便讀者深刻學習，本系列連載都會將做者研究過android

程中所學習的參考文獻列出來數據庫

第2章深刻理解Netd編程

本章主要內容

介紹Netd;
介紹MDNS和Apple Bonjour技術;
介紹iptables、tc和ip等Linux系統中經常使用的網絡管理工具;
介紹Netd中的各個命令對象和相關的背景知識;
介紹NetworkManagmentService。

2.1 概述

Netd是Android系統中專門負責網絡管理和控制的後臺daemon程序，其功能主要分三大塊：windows

設置防火牆（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系統中網絡相關消息和命令轉發及處理的中樞模塊。api

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]而啓動，其配置項如圖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]

int main() {

CommandListener *cl;

NetlinkManager *nm;

DnsProxyListener *dpl;

MDnsSdListener *mdnsl;

ALOGI("Netd 1.0 starting");

//爲Netd進程屏蔽SIGPIPE信號

blockSigpipe();

//①建立NetlinkManager

nm = NetlinkManager::Instance();

//②建立CommandListener，它將建立名爲"netd"的監聽socket

cl = new CommandListener();

//設置NetlinkManager的消息發送者（Broadcaster）爲CommandListener。

nm->setBroadcaster((SocketListener *) cl);

//啓動NetlinkManager

nm->start();

......

//注意下面這行代碼，它爲本Netd設置環境變量ANDROID_DNS_MODE爲"local"，其做用將在2.2.4節介紹

setenv("ANDROID_DNS_MODE", "local", 1);

//③建立DnsProxyListener，它將建立名爲"dnsproxyd"的監聽socket

dpl = new DnsProxyListener();

dpl->startListener();

//④建立MDnsSdListener並啓動監聽，它將建立名爲"mdns"的監聽socket

mdnsl = new MDnsSdListener();

mdnsl->startListener();

cl->startListener();

while(1) {

sleep(1000);

}

exit(0);

}

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]

int NetlinkManager::start() {

//建立接收NETLINK_KOBJECT_UEVENT消息的socket，其值保存在mUeventSock中

//其中，NETLINK_FORMAT_ASCII表明UEvent消息的內容爲ASCII字符串

mUeventHandler = setupSocket(&mUeventSock, NETLINK_KOBJECT_UEVENT,

0xffffffff, NetlinkListener::NETLINK_FORMAT_ASCII);

//建立接收RTMGPR_LINK消息的socket，其值保存在mRouteSock中

//其中，NETLINK_FORMAT_BINARY表明UEvent消息的類型爲結構體，故須要進行二進制解析

mRouteHandler = setupSocket(&mRouteSock, NETLINK_ROUTE, RTMGRP_LINK,

NetlinkListener::NETLINK_FORMAT_BINARY);

//建立接收NETLINK_NFLOG消息的socket，其值保存在mQuotaSock中

mQuotaHandler = setupSocket(&mQuotaSock, NETLINK_NFLOG,

NFLOG_QUOTA_GROUP, NetlinkListener::NETLINK_FORMAT_BINARY);

return 0;

}

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]

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策略路由」，中文文檔，知識面覆蓋較全，屬於入門級資料。

[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方面的知識，知識覆蓋面較全。屬於入門資料。

「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中各個選項的做用。

「用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

本章主要內容

2.1 概述

2.2 Netd工做流程分析

2.2.1 main函數分析

2.2.2 NetlinkManager分析

2.2.3 CommandListener分析

2.2.4 DnsProxyListener分析

1. Android DNS介紹[3]

2. getaddrinfo函數分析

3. DnsProxyListener命令介紹

1. Apple Bonjour技術介紹[4][5][6]

2. MDnsSdListener分析

2.5 本章總結和參考資料說明

2.5.1 本章總結

2.5.2 參考資料說明

Linux PF_NETLINK相關資料

DNS、Apple Bonjour相關資料

iptables相關資料

TC相關資料

IP命令相關資料

NetDevice編程文獻

Linux策略路由相關資料

Linux IPv6控制相關資料

TTY和ptmx編程相關資料

PPP和Pppd相關資料

NAT相關資料

Tether、RNDIS、DHCP、DNSmasq相關資料

Softap和hostapd相關資料

《深刻理解Android：Wi-Fi，NFC和GPS》章節連載[節選]--第二章 深刻理解Netd

本章主要內容

2.1 概述

2.2 Netd工做流程分析

2.2.1 main函數分析

2.2.2 NetlinkManager分析

2.2.3 CommandListener分析

2.2.4 DnsProxyListener分析

1. Android DNS介紹[3]

2. getaddrinfo函數分析

3. DnsProxyListener命令介紹

1. Apple Bonjour技術介紹[4][5][6]

2. MDnsSdListener分析

2.5 本章總結和參考資料說明

2.5.1 本章總結

2.5.2 參考資料說明

Linux PF_NETLINK相關資料

DNS、Apple Bonjour相關資料

iptables相關資料

TC相關資料

IP命令相關資料

NetDevice編程文獻

Linux策略路由相關資料

Linux IPv6控制相關資料

TTY和ptmx編程相關資料

PPP和Pppd相關資料

NAT相關資料

Tether、RNDIS、DHCP、DNSmasq相關資料

Softap和hostapd相關資料

《深刻理解Android：Wi-Fi，NFC和GPS》章節連載[節選]--第二章深刻理解Netd