Netlink socket

RFC3549［29］所描述的Netlink socket是使用者空間的程式和核心交換訊息 也是最常用的方式。Netlink socket 可以使用標準的 socket API開啟、關閉，接 收和發送訊息。

讓我們來看一下 socket 系統函式的原型：

int socket(int domain, int type, int protocol)

domain 參數指定了 socket 是在哪個 domain 下進行通訊。

type 參數通常為則指定了該 socket 資料傳輸的類型，如 SOCK_STREAM 提 供了有順序的、可靠性、有雙方連線基礎的資料傳輸類型，而 SOCK_DGRAM 則提供無順序、不可靠的資料傳輸類型。

protocol 參數指定了在該 domain 下的 socket 是要採用何種協定。

Netlink 使用PF_NETLINK domain，type 為 SOCK_DGRAM，並且定義了幾 種不同的 protocol，每一種 protocol都會對應到不同的核心組件。如

NETLINK_FIREWALL被防火牆所使用。Netlink 的 protocol列表在

include/linux/netlink.h文件中定義，名稱為 NETLINK_XXX。Table 2-3 顯示了一 部分的定義。而之後會介紹的rtnetlink則為 NETLINK_ROUTE的protocol。

Table 2-3 include/linux/netlink.h 中關於 protocol 的定義部份

#define NETLINK_ROUTE 0

/* Routing/device hook */

…

#define NETLINK_FIREWALL 3 /* Firewalling hook */

如同一般的 IP 訊息有 IP 表頭一樣，Netlink 的訊息也有 Netlink 的表頭。

Figure 2-6 Netlink Message Format

Table 2-4 顯示了 netlink 的表頭的定義，這邊比較重要欄位的是 nlmsg_type，

這個 2 bytes 的欄位定義了接在netlink表頭後面資料要如何解釋。

Table 2-4 netlink 表頭的定義

struct nlmsghdr {

u32 nlmsg_len;

/* Length of message including header */

u16 nlmsg_type;

/* Message content */

u16 nlmsg_flags;

/* Additional flags */

u32 nlmsg_seq; /* Sequence number */

u32 nlmsg_pid;

/* PID of the process that opened the socket */

};

在 netlink socket 中，所要傳送訊息都需要指定端點的 id，而端點 id 通常是 用打開 socket 的使用者程式的 PID (process identification) 來表示，而 0 通常就代 表核心。

netlink 的一個特性就是可以發送單點和廣播的訊息：即目標端點可以是使用 者空間的程式的 PID 或著是廣播的 id。Linux 核心中已經定義了幾個廣播的 id，

用於發送特定事件的通知，如果使用者空間的程式對某類事件感興趣，可以把 PID 註冊到相對應的廣播 ID 中。

廣播ID的定義在 include/linux/rtnetlink.h中，名字類似 RTMGRP_XXX，可參 考 Table 2-5。其中RTMGRP_IPV4_ROUTE和RTMGRP_NEIGH兩組廣播ID，分 別用於通知路由表和L3 及L2 的更改資訊。

Table 2-5 include/linux/rtnetlink.h 關於廣播事件的定義部份

rtnetlink 是架構在 netlink 上的訊息，要使用 rtnetlink 的訊息就是在開 netlinksocket 時以 NETLINK_ROUTE 作為 protocol 的參數。

rtnetlink 也有自己的訊息分類，每個分類都有自己的屬性 (Attribute) 資料，

不同的屬性資料需要根據目前所收到的 rtnetlink 訊息為哪一類來解釋。每個屬 性資料前面也會有個屬性表頭，用於告知後面接的屬性資料的解釋。

Table 2-6 顯示了屬性表頭的定義，rta_len表示後面接的資料長度，rta_type表示 要如何解釋後面接的屬性資料。

Table 2-6 屬性表頭 ratttr 的定義

struct rtattr {

unsigned short rta_len;

unsigned short rta_type;

}

而目前收到的訊息類型就定義在 netlink 表頭的 nlmsg_type 欄位中。以下列 出目前 rtnetlink 所擁有的部分訊息分類：

z NEIGHBORS

„ 關於 ARP Table 的訊息 z RULES

„ 關於路由規則的訊息 z DISCIPLINES

„ 網路佇列相關訊息 z CLASSES

„ 網路傳輸分類相關訊息 z FILTERS

„ 網路傳輸過濾器相關訊息

Figure 2-7 rtnetlink 訊息格式

Figure 2-7 顯示了 rtnetlink架構在netlink上的訊息格式，我們可以看到它就只是 一連串帶著屬性的資料而已。而前面有一個 rtnetlink 的表頭。rtnetlink 的表頭 也是會根據不同的rtnetlink訊息類型而有不同的解釋方式。

本論文的事件通知機制和系統有關的部份就是架構在 rtnetlink 下，我們去擴 充 Linux 核心下的 rtnetlink 功能來達到我們所定義的各種事件通知。

與 Linux 其它使用者空間與核心空間的訊息交換機制相比，比如和 ioctl 相 比，netlink 的一個優勢就是可以初始化一個傳輸過程而不僅僅只是對使用者空間 程式的請求返回應答訊息。在 netlink 下，使用者空間應用程式和核心層間是有 連線狀態存在的，所以核心空間有訊息產生時可以直接傳送給使用者空間，而 ioctl 的呼叫返回模式是沒辦法作到由核心主動傳送訊息給使用者空間程式的。

第 3 章 相關研究

3.1 IEEE 802.21 Media Independent Handover Services

關於本節更詳細的內容可以參考 ［30］。

在 2004 年 3 月 IEEE 802.21 工作小組正式成立，802.21 是由 Intel 所主導之規 格，其目的為使行動裝置在不同網路之間漫遊時，提供相關異質網路技術界接，

且能自動選擇最好用的網路連接類型，並無縫隙地切換通訊路徑。

802.21 之核心在於 Media Independent Handover Function （MIHF），其主要功 能在將資料連接層中之 802.11，802.16 或 Cellular 等不同無線技術之 MAC、PHY，

用一共同介面將資料成功切換至網路架構中 Layer 3 以上之層級。

Figure 3-1 顯示整個 802.21 整體架構，MIHF共定義了三個不同的服務：Media Independent Events Service (MIES)、Media Independent Command Service (MICS) 與Media Independent Information Service (MIIS)

三

Figure 3-1 802.21 Overview［30］

整個 MIH Function 運作，首先在使 Layer2 之不同網路技術透過 MIES 向上傳 遞，而上層如 SIP、IPv4、及 IPv6 等也可透過 MICS 往下層傳達命令，最後透過 MIIS 提供 MIFH 實體層能夠發現在搜尋範圍內之訊息。

透過 802.21 能讓聲音 (Voice) 及影像 (Video) 等講求及時 (Real-time) 之應 用可依環境所需速度適時切換至所需網路，而不產生訊號延遲現象。

目前在 IEEE 802 之各種傳輸技術中，並沒有無縫隙界接之機制，因此在 802.11 技術已成熟及 802.16 技術也已問世，802.21 所扮演的角色將趨於重要。將 Wi-Fi、

WiMAX 及 WWAN 之間透過其 MIH、Information Service 及 Smart Trigger 等三大 802.21 重要功能，順利將異質網路間訊號順利串接，也將左右整合三大網絡之終 端產品發展。

3.2 Gollum (Toward Open and Unified Link-Layer API)

關於本節更詳細的內容可以參考 ［31］及

http://www.ist-gollum.org/。

GOLLUM (Generic Open Link-Layer API for Unified Media Access) 是從 2004 年 9 月開始，目前仍在進行中的研究計畫。這個計畫的目標在於發展創新的與網 路程式相關的中介軟體、及程式介面，用來解決應用程式設計在異質無線行動網 路下所衍生的問題。

GOLLUM 計劃研究和設計一套公開的、獨立於作業系統的 Link-Layer API (ULLA; Universal Link Layer API)，用來統一應用程式及作業系統存取和設定不 同有線及無線網路的介面。有了統一的 link-layer 存取介面，應用程式設計將不 再需要熟悉大量現存不同無線攫取技術的 API，對於行動網路應用程式的開發將 會是一大福因。統一的應用程式設計介面，也會增進異質無線網路使用之間的相 容性和也會使應用程式在不同無線攫取技術下移植更容易進行。GOLLUM 計劃 的目標便是設計一套具有彈性和新型提供行動相關資訊和事件功能的應用程式 介面，用來簡化無線網路應用程式的開發，提供未來更具智慧和創意的無線應用。

由本節和上一節的介紹，我們可以知道在未來行動裝置可以搭載各種不同的 網路模組的趨勢下，各大廠商都積極發展獨立於不同網路模組的應用程式界面，

用來將網路界面卡的異質性隱藏起來，並且也提供事件通知機制，讓上層的協定 可以快速地知道底層網路界面的狀態。

Figure 3-2 ULLA API 和相關事件查詢、中介軟體關係圖示

Figure 3-2 顯示了各種不同的無線網路存取技術可以經由 ULLA 整合起來。

Gollum 和 802.11 一樣也都處於發展階段，目前只有提出一個整體的大架構，

對於程式界面或著 Link Layer 的事件都還未有詳細定義的文件。

3.3 Linux 平台上驅動程式層網路事件通知機制

［32］是本實驗室之前所發展的系統。該系統將網路介面相關的狀態改變利用 類似傳統UNIX作業系統上的信號 (signal) 機制通知使用者空間的程式，並且修 改了排程的演算法，使得使用者空間程式不必一再地發出系統呼叫，加快對於網 路介面狀態改變的處理，以增進系統效能。

該系統之實作可以分為三個主要部分：

z 事件通知部分 (Event notification) z 行程管理 (process management) z 排程器 (scheduler)

當網路驅動程式相關訊息發生以後，該系統的目標是由核心空間直接切換至 使用者空間來執行。也就是說，在行程從核心空間回到使用者空間之前，該系統 會去檢查是否有該行程所註冊的事件發生，當有註冊的事件發生時，系統會先執 行該行程所註冊的對應處理函式，接下來，利用系統呼叫返回核心空間，並且在 該系統呼叫內回覆原來所應該執行行程的硬體環境 (hardware context) 。

關於使用者空間和核心空間的切換，該系統利用了 Linux 下的兩種堆疊 – 核心模式堆疊 (kernel mode stack) 和使用者模式堆疊 (user mode stack) ；核心模 式堆疊主要作用有兩點，記錄使用者硬體環境 (hardware context) 以及存放程序 敘述子。

當要跳至使用者空間執行行程註冊的回叫 (Callback) 函數之前，因為在 Linux 中每次由核心空間返回使用者空間都會將核心模式堆疊清空，如此一來，

當使用者由回叫函數返回核心空間時，原本用以執行一般程式碼的硬體環境會消 失；因此該系統將核心模式堆疊中的硬體環境存至別的地方，以免原本的硬體環 境消失，因此，該系統將原本的硬體環境儲存在使用者模式的堆疊中，等到由回 叫函數返回後，再將其復原。

系統核心內的關係如 Figure 3-3 所示。當網路事件發生時，通用驅動程式 (Generic Driver Layer)會去呼叫 Event Handler，Event Handler 就會去更改核心用 來處理程序的資料結構，通知有事件發生，當排程器排到該程序時會先檢查是否 有事件發生，有的話，就會去執行程序所註冊的回叫函式。

Figure 3-3 Linux平台上驅動程式層網路事件通知機制的系統元件架構和關係 ［32］

第 4 章 支援網路感知之中介軟體設計與架構

本章將介紹本論文所提的支援具網路感知應用程式的中介軟體設計架構。我 們將此中介軟體命名為 WinME。

4.1 目標與問題定義

本論文的主要目標是發展一個應用程式平台，讓程式設計者可以用來開發具 網路感知的應用程式，因此我們有以下的子目標：

z 應用程式可以取得網路資訊

„ 應用程式可以主動要求網路相關資訊。

z 當網路狀態改變時，應用程式可以被通知

„ 應用程式可以被動的被通知事件的產生，不需要去使用系統呼叫輪詢網 路狀態是否改變。

z 程式設計者可以只註冊自己感興趣的事件

z 程式設計者開發網路程式時不需擔心網路相關的系統程式碼

z 行動管理員程式可以控制協定堆疊各層的資訊 (e.g. 設定 IP 位址等…) 為達以上的目標，我們會有以下的問題：

z 應用程式如何取得網路資訊？

z 如何提供事件驅動機制？

z 程式界面的定義。

z 程式界面的定義。

在文檔中 支援具網路感知應用程式的中介軟體之設計與實作 (頁 31-0)