深度探秘

兩個都因「裝置變小、無線變多」而生，但著重點不同

一切的起點：微型化 + 無線連線

以前電腦又大又重，只能放在桌上或機房。後來兩件事改變了一切：

1. 裝置微型化：電腦愈做愈小，小到可以隨身帶、可以穿戴、甚至嵌進桌子、車子、衣服裡。
2. 無線連線普及：這些小裝置不用接線就能互相連、也能連到傳統的 PC 與伺服器。

這兩股力量催生了兩個密切相關但著重點不同的領域：

ubiquitous 的意思就是「無所不在」，也常被稱為 pervasive computing，兩者通常當同義詞用。

三個子領域

• 手持運算 (handheld)：smart phone、PDA 等握在手裡的裝置，犧牲體積與電力來換運算力與螢幕大小的限制。
• 穿戴運算 (wearable)：像手錶、眼鏡、夾在衣服上的裝置，常常不需使用者操作就自動運作（例如早期的 active badge）。
• 情境感知運算 (context-aware)：系統依「實體狀況」自動調整行為，例如手機在電影院自動轉震動。

生活妙喻

從『一人一台電腦』到『一人很多台電腦』

想像電腦使用方式的三個時代

• 大型主機時代：一台電腦，很多人共用（像全村只有一口井，大家排隊打水）。
• 個人電腦時代：一人一台電腦（每家自己有水龍頭）。
• 普及運算時代：Mark Weiser 預言「一人，很多台電腦」——但不是說你有公司一台、家裡一台、再加筆電手機那種「好幾台很像的電腦」。

Weiser 的「一人多電腦」是指：電腦在形式與功能上也跟著繁衍，每種任務配一種電腦。

把房間裡的東西都變成電腦

想像一間房間裡所有「會寫字、會顯示」的表面——白板、書、便利貼、紙——全換成幾十上百個有電子顯示的小電腦；連筆都能記住你寫過畫過什麼，還能在這些電腦間搬移內容。這就是「運算無所不在」的感覺。

第二個預言：電腦會『消失』

Weiser 還說，電腦會「織進日常生活的織物裡，直到我們察覺不到它」。就像你不會把洗衣機、汽車當成「電腦」，雖然它們裡面其實塞了一堆微處理器（有些車甚至約 100 顆）。這是一種心理上的隱形：好用到你忘了它存在。

實用超能力

情境感知手機與 active badge

active badge：最早的穿戴裝置

active badge 是一個夾在衣服上的小裝置，會定時用紅外線廣播自己的身分（對應到某位使用者）。因為紅外線傳輸距離很短，只有當使用者靠近時，環境中的裝置才會收到。

flowchart TD
  A[使用者戴著 active badge 進入房間] --> B[紅外線感測器偵測到使用者 ID]
  B --> C[顯示器依使用者偏好調整]
  C --> D[例如改變預設畫筆顏色與線條粗細]

房間也可以依偵測到的使用者，自動調整冷氣與燈光到他偏好的設定。這就是 context-aware computing 的雛形：系統依「誰在場」這種實體狀況自動反應。

情境感知有難有易

• 容易判斷的情境：例如「現在是不是晚上」——靠時間、日期、地理位置就能算出來。
• 困難判斷的情境：例如一支手機要「該響時才響」，在電影院裡要自動轉震動。但要分辨使用者是「正在看電影」還是「只是站在電影院大廳」，因為位置感測本身就有誤差，這非常不容易。

連線的兩個網路層難題

行動裝置帶來兩個要解的問題：

1. 裝置進出基地台範圍時，如何維持連續連線。
2. 在沒有基礎建設的地方，裝置群如何彼此無線溝通（ad hoc 網路）。

為什麼無線常常不能直連？因為範圍愈大、搶頻寬的裝置愈多；而且傳輸能量大致與距離平方成正比，但裝置電量有限。

深度探秘

為什麼叫『易變（volatile）』系統

易變：變動是常態而非例外

本書其他章節大多假設「故障是例外」，但行動與普及系統不同：使用者、硬體、軟體的集合高度動態、不可預測地變化。我們稱這類系統為 volatile（易變），也常用 spontaneous（自發） 來形容。

易變性的三種主要來源：

• 裝置與通訊鏈路的故障；
• 通訊特性（如頻寬）的變化；
• 元件間關聯（association）的建立與消滅——這是最特別的一項。

注意：這裡的「元件（component）」泛指任何軟體單位（物件、行程），不管它扮演 client、server 還是 peer。

易變性不是行動／普及系統的專利

別誤會：P2P 檔案分享（第 10 章）也很易變，參與的行程與彼此關聯都高速變化，但它既非行動也非普及。

行動與普及系統的不同在於：它們同時展現上述所有形式的易變性，而且這是因為它們與實體世界整合所致。實體整合本身不是分散式系統的性質，但易變性是，所以我們採用「易變」這個詞。

生活妙喻

智慧空間就像一間不斷有人進出的咖啡廳

智慧空間：嵌有服務的實體場所

智慧空間 (smart space) 是任何「嵌有服務」的實體場所——也就是只在那個地方（或主要在那裡）提供的服務。例如一個房間、建築、車廂、廣場。它通常含有相對穩定的基礎建設：伺服器、印表機、顯示器、感測器、無線網路與對外連線。

把智慧空間想成一間咖啡廳：

• 店裡的桌椅、Wi-Fi、收銀機是穩定的基礎建設。
• 客人不斷帶著手機、筆電走進走出——這是實體移動。
• 客人裝置裡的某個 app 或行程可能搬進搬出——這是邏輯移動（但只有當它因此改變了關聯才算有意義）。
• 有人買了新的智慧音箱長期放在店裡（較靜態的增減）。
• 某台裝置沒電當機，等於從空間中「消失」。

變化速率很重要

一個智慧家庭可能一天才幾個裝置進出；但一個擁擠城市裡用 Bluetooth 互連的手機群，任何時刻都至少有一個變動。前者與後者的演算法設計可能截然不同。

從安全角度看，「使用者的裝置進入空間」和「外來軟體元件移到空間的基礎裝置上」是兩回事，不能一概而論。

實用超能力

裝置模型：能量、資源、感測器與致動器

一種新的裝置類別

行動與普及運算帶來一種新裝置，它的裝置模型必須考慮三件事：

兩個量產實例

flowchart TD
  A[新裝置類別] --> B[Mote 微塵]
  A --> C[Smart phone 智慧手機]
  B --> B1[低功耗微控制器跑 TinyOS]
  B --> B2[短距無線收發 偵測森林火災等]
  C --> C1[跑 Symbian Android iOS]
  C --> C2[內建 GPS 磁力計 加速度計 相機]

• Motes（微塵）：小到被稱為「smart dust」，設計來嵌入環境自主運作，例如散布森林中偵測高溫並透過彼此把訊息傳給更強的裝置。
• Smart phones：主功能是通訊與影像，但可跑各種 app，常配 GPS、磁力計、加速度計，還能用相機讀條碼當「編碼值的感測器」。

深度探秘

連線會斷、頻寬會抖；而『關聯』是另一回事

易變連線：無線比有線更容易斷

本章的裝置都靠某種無線連線，而無線連線的易變性——連與斷、服務品質的執行時變化——強烈影響系統性質。主要問題有兩個：

• 斷線 (disconnection)：裝置移動超出範圍、被建築物等遮蔽（occlusion）都會斷線；即使裝置靜止，移動的人車也會造成遮蔽。還有 ad hoc 路由 的多跳問題：你跟鄰近節點都通，卻可能因為更遠的中繼節點故障而傳不出去。
• 頻寬與延遲變動：同樣的因素會讓錯誤率改變，封包被丟得越多，吞吐越低。上層協定的 timeout 很難調：太大則延遲吞吐受害，太小則增加壅塞、浪費能量。

關聯 ≠ 連線

• 關聯 (association)：一對元件中至少一方在某段明確時間內與另一方溝通，所形成的邏輯關係。
• 互通 (interoperation)：它們在關聯期間的實際互動。

關鍵：關聯與連線是兩回事。筆電上的 email client 與 email server 可能此刻斷線，但它們仍維持關聯。

生活妙喻

預先配好的朋友 vs. 路上認識的新朋友

自發互通：關聯會例行性地改變

在易變系統中，元件會隨著移動或別人出現而例行性地更換溝通對象。本書用一張圖把關聯分成「預先設定」與「自發」兩大類：

把它想成交朋友：

• 預先配好的朋友：像你早就存好號碼的老同學（email server），長期值得，設定成本相對小。
• 路上認識的新朋友：web 是人為驅動（你看心情點連結）；P2P 是資料驅動（為了某首歌才加好友）；行動／普及則是實體驅動——誰剛好走到你旁邊，就跟誰建立關係，主要看鄰近性。

Web 之所以成功，部分是因為「換關聯幾乎不費力」——網頁作者早就幫你把連結設定好了。

實用超能力

為什麼信任與隱私被削弱了

降低的信任

第 11 章說過：分散式系統的安全最終建立在可信計算基礎 (trusted computing base) 上。但易變系統的信任很麻煩，因為自發互通：能彼此自發關聯的元件之間，憑什麼信任？

它們可能分屬不同的個人或組織，彼此毫無先前認識，也沒有共同的可信第三方。這讓傳統那套「先建立信任再溝通」的做法難以套用。

受威脅的隱私

智慧空間裡布滿感測器，意味著可以前所未有的大規模電子追蹤使用者。

flowchart TD
  A[使用者享受情境感知服務] --> B[空間依偏好調整冷氣燈光]
  B --> C[但他人可學到你去過哪 做過什麼]
  C --> D[更糟的是你常常不知道自己正被感測]
  D --> E[即使不透露身分 也可能被推斷出來]
  E --> F[例如固定通勤路線加上中途刷卡記錄]

重點：即使你沒主動透露身分，別人仍可能藉由規律行為 + 其他線索（如固定家與公司間的往返，加上中途的刷卡）拼湊出你是誰、在做什麼。這就是隱私在感測無所不在時代的脆弱之處。

深度探秘

裝置出現後要做兩件事：先上網，再找對象

兩個步驟

裝置出現在智慧空間，且最好不用使用者介入，就得自己完成：

1. 網路啟動 (network bootstrapping)：先取得本地網路位址（或註冊既有位址如 mobile IP），可能也取得或註冊一個名稱。
2. 關聯 (association)：裝置上的元件要嘛去關聯空間裡的服務、要嘛對外提供服務，或兩者皆是。

網路啟動怎麼做

• 靠伺服器：例如 DHCP server（見 3.4.3）可發 IP 與 DNS 參數，裝置向一個眾所周知的廣播位址查詢即可取得；也可用 dynamic DNS 更新服務註冊新 IP。
• 無伺服器：在沒有任何服務基礎建設時也要能配位址——這既能簡化空間，也能避免對可能故障的服務產生依賴。IPv6 含無伺服器位址指派協定；IETF 的 Zeroconf 工作小組在制定相關標準，Apple 的 Bonjour 是商業實作。

共同點：這些方法都用本地網路上的廣播或多播到一個眾所周知的位址，任何裝置都能在該位址上收聽或傳送。

生活妙喻

在飯店找『你房間裡』的印表機

關聯問題的兩個面向

能在空間裡溝通之後，裝置面臨關聯問題：要跟誰互通？要解決兩個面向：

• 規模 (scale)：空間裡可能有很多裝置，裝置上又有更多軟體元件。該跟哪些互通？怎麼有效率地選？
• 範圍 (scope)：怎麼把考量限制在這個智慧空間裡的元件——而且是空間裡的全部元件——而非空間外那潛在數兆個元件？

飯店印表機的比喻

想像你住飯店，想從筆電列印文件。

• 你不可能事先知道飯店印表機叫什麼名字（像 \\myrtle\titus 這種誰猜得到）。
• 你要找的是你這間房的印表機，不是隔壁房的——這就是範圍問題。
• 如果你房裡剛好有合適印表機，解法也應該把它納入候選——不能漏掉。

範圍部分是規模問題，但不只是。智慧空間通常有管理與領域邊界，這對使用者和管理員意義重大。

實用超能力

邊界原則：系統邊界要吻合人對空間的認知

邊界原則 (boundary principle)

邊界原則：智慧空間的系統邊界，應準確對應到人們在領域與管理上正常定義的有意義空間。

這些「系統邊界」是系統定義的判準，用來劃定範圍 (scope) 關聯——但不必然限制 (constrain) 關聯。

為什麼網路探索常違反它

一個常見解法是用探索服務 (discovery service)，而它通常基於子網路多播 (subnet multicast)。問題在於：子網路的觸及範圍不一定吻合空間裡實際可用的服務。

flowchart TD
  A[飯店房間 你的智慧空間] --> B[子網路多播觸及範圍]
  B --> C[訊號穿牆 誤含隔壁房印表機]
  B --> D[空間內服務卻被託管在子網路之外 被漏掉]
  C --> E[違反邊界原則]
  D --> E

• 誤含：RF 訊號（802.11、Bluetooth）會穿牆到隔壁房，把不屬於你空間的服務也算進來。
• 漏掉：有些「在」空間裡（合該被你發現）的服務，卻託管在子網路之外（如 Cooltown 案例中的印刷文件對應的線上服務）。

所以後面 19.2.2 會介紹靠實體參數與人為輸入來做出更精準範圍的方法。

深度探秘

會處理易變性的『目錄服務』

探索服務是什麼

客戶端用探索服務 (discovery service) 來得知智慧空間裡提供了哪些服務。它本質上是一個目錄服務 (directory service)：服務依其屬性 (attributes) 註冊，客戶端依屬性查找——但它的實作要顧及易變性：

1. 客戶端需要的目錄資料是執行時才決定的（依當下身處哪個智慧空間）。
2. 空間裡可能沒有基礎建設來架目錄伺服器。
3. 註冊的服務可能自發消失。
4. 存取目錄的協定要對能量與頻寬敏感。

介面長怎樣

探索服務有「註冊／登出」和「查找」兩組介面（圖 19.3 的簡化版）：

lease := register(address, attributes)   // 註冊服務，回傳一個 lease
refresh(lease)                           // 更新租約
deregister(lease)                        // 移除註冊
serviceSet := query(attributeSpecification) // 查找符合屬性的服務集合

注意：探索服務本身不完成關聯。從回傳的集合中選一個服務（service selection）是另一步，可程式化選或列給使用者選。

生活妙喻

推播廣告 vs. 拉取詢問，以及『租約』這張到期票

有伺服器 vs. 無伺服器

• 目錄伺服器式：一台伺服器存所有服務描述、回應查詢。元件先多播找它，它回傳 unicast 位址，之後點對點溝通（省得吵醒無關裝置）。適合有基礎建設、可插市電的空間。
• 無伺服器式：沒有伺服器時，參與裝置協作實作分散式探索，有兩種模型：

可設計混合協定截長補短。

租約 (lease)：一張會到期的票

服務可能正常 deregister，也可能自發消失。伺服器靠租約處理：租約是伺服器暫時配給客戶端的資源，到期前必須由客戶端再請求才能續租（refresh）。沒續租，伺服器就收回（並可能重新配置）。

取捨：租約越短，越快發現服務消失，但越耗網路與能量。無伺服器架構則不必特別處理——消失的服務不再廣告，拉取式客戶端自然只會發現還在的服務。

實用超能力

Jini：用群組名稱劃定範圍

Jini 的探索系統

Jini 全基於 Java，假設所有電腦都跑 JVM，用 RMI 或事件溝通，並能依需要下載程式碼。它有三種角色：lookup service（查找服務）、Jini service、Jini client。

• Jini service 把它提供的服務（連同一個可存取該服務的物件與屬性）註冊到一或多個 lookup service（註冊在 Jini 稱為 join）。
• Jini client 向 lookup service 查找符合需求的服務；若找到，就下載一個能存取該服務的物件。
• 比對可基於屬性或 Java typing（例如要一台有對應 Java 介面的彩色印表機）。

用群組名稱劃定範圍

啟動時，client 或 service 對眾所周知的 IP 多播位址送出請求；能回應的 lookup service 回傳位址。每個 lookup service 可設定一或多個群組名稱（如 admin、finance、sales）當作劃範圍的標籤。

flowchart TD
  C[Client 需要 finance 群組] -->|1 多播 finance lookup service| L[Finance 群組的 Lookup service]
  L -->|2 這是我的位址| C
  C -->|3 RMI 請求 printing 服務| L
  L -->|4 回傳存取 printing 的物件| C
  C -->|5 直接使用 printing 服務| P[Printing service]

圖中只有一個 lookup service 綁在 finance 群組，它回應 client；client 再用 RMI 直接向它找 printing 類型的服務，拿到存取物件後直接使用。另有一個 admin 群組的印表機，以及未綁任何群組的企業資訊服務。

深度探秘

網路探索的不足，用『物理』來補

為什麼要靠物理

上一節說過，純網路探索常違反邊界原則（穿牆誤含、漏掉外部服務），且服務描述語彙可能不一致（你找 Printing，對方叫 Print）。實體關聯 (physical association) 用物理手段補足這些不足，代價通常是需要更多人為參與。

三類技術

本節介紹三大類：

1. 人為輸入來劃定範圍：使用者直接給裝置一個空間識別碼（如輸入或選擇飯店房號），裝置把它當成額外的服務「群組」屬性（如同 Jini）。
2. 感測與受實體限制的通道來劃定範圍：用感測器讀取空間裡的識別碼，或用只在空間內傳播的通道。
3. 直接關聯：人用物理機制把兩個裝置直接配對，不經探索服務。

核心精神：與其讓子網路範圍亂猜，不如讓人或物理現象來告訴系統『你現在在哪、要跟誰配對』。

生活妙喻

掃一下電視上的房號，就像對暗號

感測與受限通道

比起手動輸入房號，更省事的是用裝置上的感測器：

• 空間裡把識別碼編成 glyph（符號） 貼在文件或表面上（如顯示在飯店房間電視螢幕），你用相機手機解碼取得識別碼。
• 室外則可用感測器取得空間的經緯度，送到一個眾所周知的廣域服務，回傳本地探索服務的位址（但衛星定位誤差大，附近若有別的空間就可能不夠精準）。

還有一招是用受實體限制的通道 (physically constrained channel)——大致只在空間物理範圍內傳播的通道：

• 電視低音量播背景音樂，把房號用人耳聽不到的擾動疊在訊號裡。
• 房裡放一個紅外線信標 (beacon) 廣播識別碼。

這兩種通道都會被房間邊界的材質大幅衰減（假設門窗關著），所以訊號出不了房間——像只有房裡的人聽得到的『對暗號』。

實用超能力

直接關聯：碰一下、照一下、一起搖一搖

直接關聯的三種手法

當裝置只提供一兩種可由人選的服務時，可讓人用物理機制讓自己的裝置學到目標裝置的網路位址（如 Bluetooth 或 IP）：

兩按鈕協定與『一起搖』

兩按鈕協定 (two-button protocol)：兩裝置都在眾所周知的多播位址上聆聽；使用者幾乎同時按下各自裝置的按鈕，裝置就把網路位址送到該多播位址。同一子網路同一時刻不太可能有另一輪協定，所以裝置就用『按鈕後極短時間內收到的位址』來配對。

flowchart TD
  A[使用者幾乎同時按下兩裝置按鈕] --> B[兩裝置各自把位址送到多播位址]
  B --> C[在極短時間窗內收到對方位址]
  C --> D[兩裝置完成配對]

還有個有趣（雖少實用）的物理版本：把兩個裝置握在同一隻手裡一起搖，各自的加速度計記下搖動模式、算出識別碼並多播；只有經歷完全相同加速度模式且在直接通訊範圍內的兩裝置，才會認出彼此。

深度探秘

互通的最大障礙：介面不相容

關聯之後，要能『對話』

上一章解決了元件如何關聯；現在問：關聯後怎麼互通 (interoperation)？也就是用什麼協定溝通、用什麼程式設計模型互動。

傳統的 IPC、方法呼叫、程序呼叫（第 4、5、6 章）多半假設：互通的元件是為了特定系統一起設計的，元件集合的變動是長期設定問題或偶發錯誤。但這假設在行動／普及系統裡不成立。

介面不相容

最大的障礙是軟體介面不相容。例如數位相機想呼叫 pushImage，但數位相框介面裡沒有這個操作，它們就無法直接互通。

理想目標：一個元件即使到了不同類型的智慧空間，也能與功能相容的元件互通（避免「失去的機會」問題，例如相機因不認得相框的服務而沒法傳照片）。但這需要軟體開發者間的全球協議——而協議成本很高，所以最好把需要協議的東西降到最少。

生活妙喻

翻譯官 vs. 大家都講同一句『通用語』

兩種解法

解法一：讓介面異質，但互相轉接 (adapt)。 例如相框若有個與 pushImage 同參數同語意的 sendImage，就能寫一個代理 (proxy) 把 pushImage 轉成 sendImage。像請一個翻譯官。

但這很難實現：

• 語意常常也不同（不只語法），克服語意不相容很難又易錯。
• 規模問題：有 N 個介面，最多要寫 $N^2$ 個轉接器，而介面只會越來越多。
• 元件無法預載所有 $N^2$ 個轉接器，得在執行時找到並載入正確的——非常麻煩。

解法二：限制介面在盡量廣的元件類別中『語法相同』。 聽起來不切實際，但其實成功實行了數十年——像大家都講同一句通用語。

• UNIX pipe：只有 read 與 write 兩個操作。因為介面標準化又有泛用文字處理能力，任一程式的輸出能餵進另一程式的輸入，自由組合。
• Web：HTTP 方法集小而固定，client 通常只用 GET 與 POST。固定介面讓相對穩定的瀏覽器能與不斷演化的服務互通——變的只是內容的型別與值、與伺服器的處理語意，每次互動仍是 GET 或 POST。

實用超能力

資料導向 vs. 物件導向的取捨

資料導向系統

用不變的服務介面（如 UNIX pipe、Web）的系統，稱為資料導向 (data-oriented / content-oriented)，與物件導向相對。

• 資料導向：任何知道那個固定介面的元件都能呼叫它。發布並使用一份介面規格（如 HTTP）比散布無數專屬介面定義容易太多——這也是為何最廣為使用的異質分散式系統是 Web，而不是同等規模的一堆 CORBA 物件。
• 物件／程序導向：每個物件有各式各樣的介面，只有知道其特定介面的元件才能呼叫。

取捨：彈性 vs. 健全性

flowchart TD
  A[兩種互通風格] --> B[物件導向 各自專屬介面]
  A --> C[資料導向 固定統一介面]
  B --> B1[可檢查介面簽章是否相符 較健全]
  C --> C1[彈性極高 任何知道介面者皆可呼叫]
  C --> C2[但難檢查兩元件互通是否合理]

資料導向的彈性是用健全性換來的：兩個元件不一定該互通，但程式幾乎無從檢查相容性。資料導向元件只能靠驗證送進來的資料型別來把關：要嘛用標準化的資料型別描述子當 metadata（如 web 內容的 MIME 型別），要嘛檢查資料值本身（例如 JPEG 開頭有可辨識的標頭）。

深度探秘

讓元件『匿名、間接』地互通

為什麼要間接

在易變系統中，誰在場很難追蹤。如果元件互通時不需知道彼此是誰，就方便多了。事件系統與 tuple space 都提供這種間接 (indirect) 互通。

事件系統 (event systems)

每個事件服務提供一個固定、泛用的介面：

• publisher（發布者） 發布結構化資料叫 event（事件）。
• subscriber（訂閱者） 接收事件。
• 每個事件服務有某種遞送範圍 (scope)。訂閱者只會收到：(1) 在同一事件服務發布的，且 (2) 符合其註冊規格的事件。

事件很適合宣告與處理易變系統中的變化（如裝置位置改變）。Active Badge 系統裡，應用可訂閱位置改變事件。還有複合事件 (composite events) 的問題：例如要偵測「兩使用者共處一地」，得用規則從 Arrive(user, location, time)、Leave(...) 等原始事件組合出來。

但事件系統只是轉移而非解決了普及互通問題：發布者與訂閱者仍須對事件服務、事件的型別與屬性（語法與語意）達成一致。好處是雙方不需互相識別，元件集合可透明改變——它們間接關聯。

生活妙喻

tuple space 像一塊公用佈告欄

tuple space（元組空間）

tuple space 是一種間接通訊典範：支援把結構化資料（tuple）加入空間、或從空間取出。元件間關聯與互通的基礎，是大家對 tuple 的結構與值達成共識。

把 tuple space 想成一塊公用佈告欄：

• 相機把照片『貼』上去：

< 'The leaning tower', 'image/jpeg', <jpeg data> >

• 數位相框用一個含萬用字元 * 的樣板去『撈』：

< *, 'image/jpeg', * >

相機的 tuple 有三欄、第二欄符合 MIME 字串，所以相框撈得到它、顯示照片。相機軟體只知道『把某格式的圖丟進 tuple space』，完全不知道之後誰會怎麼處理。

佈告欄的妙處：貼的人和看的人不必認識彼此，貼上去的條子甚至能比貼它的人活得久。

實用超能力

幾種實作，以及事件 vs. tuple 的差異

幾個為行動／普及打造的 tuple 系統

事件 vs. tuple 的兩大差異

flowchart TD
  A[事件 vs tuple] --> B[同步性]
  A --> C[生命週期]
  B --> B1[事件 純非同步]
  B --> B2[tuple 可同步取得 較好寫但別硬等]
  C --> C1[事件 預設不超過發布與訂閱間的傳播]
  C --> C2[tuple 可比放它的元件活得久 持久]

• 同步性：事件只能非同步；tuple space 提供同步取出操作（較好寫，但別期待某個動態遇到的裝置一定會供 tuple，因為隨時可能斷線）。
• 生命週期：事件預設不超過發布與訂閱間的傳播；tuple 卻可比放它的元件活得久。持久性有好處（相機沒電前已上傳照片仍在）也有壞處（沒人消費的 tuple 可能無限增長成垃圾，又難判斷哪些是垃圾）。event heap 就用過期機制解決這問題。

深度探秘

兩個被人帶到一起的裝置怎麼互通：JetSend 與 Speakeasy

直接裝置互通

前面的事件與 tuple 是間接關聯；JetSend 與 Speakeasy 則是設計給人帶到一起、直接關聯的兩個裝置。

JetSend

設計給相機、印表機、掃描器、電視等家電互動，刻意做成資料導向——沒有任何家電要為特定對方裝載專屬驅動。核心操作是同步狀態 (synchronize state)：把一方呈現給另一方的狀態，以雙方協商出的格式傳輸。例如掃描器與相框同步時，從掃描器能提供的多種影像格式中選 JPEG。

但同步只支援簡單互通（基本上就是資料傳輸）。更複雜的互動（如列印要選黑白還彩色）怎麼辦？來源裝置沒有特定印表機的驅動，也不可能預先寫好任意裝置的語意。JetSend 的答案：靠人。 由目標裝置（印表機）指定一個使用者介面，渲染在來源裝置上讓人選——這正是 Web 的運作方式：每個服務把介面當 markup 送到瀏覽器，瀏覽器渲染成通用元件，毋須懂服務的特定語意。

生活妙喻

Speakeasy：用『可下載的小幫手程式』

Speakeasy 與行動程式碼

Speakeasy 沿用 JetSend 的設計原則，但多一招：行動程式碼 (mobile code)。打印表機可以把任意 UI（一段可執行的小程式）送到你手機上。兩個動機：

1. 更強的 UI：行動程式碼能在本地做輸入驗證、提供 markup 做不到的互動模式。
   • 代價：執行外來程式碼有安全疑慮（需防木馬），且在虛擬機上跑比處理受限的 markup 更耗資源。
2. 最佳化資料傳輸：行動程式碼可在主機 API 限制內，與送它來的遠端裝置做任意互動，因此能為特定內容型別實作最佳化協定（如影片即時壓縮再傳）。JetSend 則只能用預先定義的傳輸協定。

把它想成：JetSend 是寄一張填好的標準表格（固定協定）；Speakeasy 是派一個會隨機應變的小幫手過去（行動程式碼），更靈活但你得提防這個外人別是壞人。

flowchart TD
  A[印表機想跟手機互通] --> B{用哪種方式}
  B -->|JetSend| C[送 markup UI 由人選功能 用預定協定傳]
  B -->|Speakeasy| D[送行動程式碼 可本地驗證並最佳化傳輸]
  D --> E[但需防木馬 且較耗資源]

實用超能力

軟狀態：可能過期、但會自動更新的提示

高可用服務 vs. 易變元件

若一個服務資源充足、高可用，元件就可以明確關聯它（記住其位址），10 分鐘後再用通常仍可達。但一般而言，易變性使不該依賴某個特定元件——它隨時可能離開或故障。

一個啟示：應該告訴程式設計師哪些服務高可用、哪些易變，並提供不依賴特定元件的程式技術。

事件系統與 tuple space 就是間接、匿名的關聯：只要事件服務或 tuple space 還在，個別元件可來來去去、被替換。

軟狀態 (soft state)

問題：易變系統裡程式怎麼管理狀態？第 18 章的複製假設資源冗餘且額外通訊，未必可行；Paxos 能在易變下達成共識但需各行程有持久儲存。

軟狀態是另一條路：提供較寬鬆但仍有用的一致性保證，即使沒有持續可用的持久儲存。Clark 提出它來管理網際網路路由器設定。大致來說，軟狀態是：

• 一種提示 (hint)——可能過期，不可依賴其嚴格時效；
• 最重要的是，來源會自動更新它。

探索服務就是範例：服務註冊條目只是提示（可能有個已消失服務的條目），而這些條目由服務的多播自動更新——加入新條目、保持現有條目新鮮。INS（Intentional Name System）也用間接關聯，假設伺服器無狀態或複製其狀態。

深度探秘

什麼是『情境』，以及感測器一定有誤差

情境 (context) 是什麼

一個實體（人、地、物）的情境，是其實體狀況中與系統行為相關的面向。包含：

• 簡單值：位置、時間、溫度、相關使用者身分、附近的人、附近裝置的存在與狀態。
• 複雜屬性：使用者的活動（如『在電影院看片』還是『散場前在聊天』）。

情境可用規則編碼，例如：『若使用者是 Fred，且他在 IQ Labs 會議室，且 1 公尺內有顯示器，則把他裝置上的資訊顯示出來——除非現場有非 IQ Labs 員工』。

感測器的誤差模型

決定情境值要從感測器 (sensor) 開始。重點：所有感測器都有誤差。

• 有些誤差落在已知容差內、分布已知（如溫度計的高斯分布）。
• 有些誤差模型很複雜（如衛星定位）：可能完全產不出值（室內牆面衰減衛星訊號），且同一地點不同時間給的值不同，只有盡力而為的精度估計；靠近高樓時可能勉強讀到但精度很低、甚至是假值。

表達誤差的好方法：引用「在指定比例的量測中達到的精度」，例如『該區內衛星定位 90% 的量測準確到 10 公尺內』；或對某次量測給一個 0 到 1 的信心值 (confidence value)。

生活妙喻

感測融合像『多位目擊者一起拼湊真相』

設計情境感知系統的四大挑戰

Salber 等人指出四個要克服的功能挑戰：

1. 整合奇特的感測器：有些感測器構造與介面很特殊，要專業知識才能正確部署（加速度計該貼哪裡才量得到手臂手勢？），還有驅動程式問題。
2. 從感測資料抽象：應用要的是抽象的情境屬性，不想管個別感測器的細節。但同一個『位置』可能是衛星的經緯度，也可能是紅外線讀到的字串『Joe’s Café』——需要對情境屬性的意義達成共識，並有軟體從原始值推論。
3. 感測器輸出常需結合：可靠地感測一個現象，往往要結合多個易錯來源。
4. 情境是動態的：應用通常要對情境變化反應，不只讀一張快照。

感測融合 (sensor fusion)

結合多個感測來源以降低錯誤，叫感測融合。比喻：要確認房裡有沒有人，麥克風（但鄰近聲音會干擾）、地板壓力（但不同人模式難分）、影像（但人臉難辨）——

就像一樁案件靠多位目擊者一起拼湊真相：每個人記得的片段都不完整、可能出錯，但綜合起來就更可靠。

實用超能力

Context Toolkit：像 GUI widget 一樣組裝情境

Context Toolkit 的 widget 架構

Context Toolkit 借用 GUI 用可重用 widget 函式庫組裝的概念：用情境 widget 呈現某類情境屬性的抽象，隱藏實際感測器的複雜性。

例如 IdentityPresence widget：

• 提供可輪詢的屬性：Location（監看的位置）、Identity（最後感測到的使用者 ID）、Timestamp（最後到達時間）。
• 提供回呼 (callbacks)：PersonArrives(location, identity, timestamp)、PersonLeaves(...)，在使用者到達或離開時觸發。

應用不必知道這資訊是用哪幾種感測器組合出來的。

widget 由分散式元件組成

flowchart TD
  G[Generators 從感測器取原始資料] --> W[Widgets 呈現抽象情境屬性]
  I[Interpreters 把低階資料抽象成高階值] --> W
  W --> S[Servers 收集儲存並詮釋多個 widget 的屬性]
  S --> PF[PersonFinder widget 封裝整棟建築的複雜性]

• generators：從地板壓力等感測器取原始資料。
• interpreters：把低階資料抽象成高階值（如從腳步聲推論是誰）。
• servers：收集、儲存、詮釋多個 widget 的情境屬性。例如整棟建築的 PersonFinder 由各房間的 IdentityPresence 組成。

評價：Context Toolkit 容納多種感測器、產出抽象屬性、能透過輪詢或回呼得知情境變化；但它沒解決整合奇特感測器、以及詮釋與結合的硬核難題。

深度探秘

一大群小節點自己組網

什麼是無線感測網路

無線感測網路 (wireless sensor network) 由（通常很多個）小型低成本節點組成，每個都能感測、運算、無線通訊。它是 ad hoc 網路的特例：節點大致隨機擺放，靠多跳 (multi-hop) 在 peer 間溝通。

重要設計目標：無需全域控制——每個節點自己發現無線鄰居，只透過它們溝通。相關技術用低功耗的 ZigBee (IEEE 802.15.4) 比 802.11 更合適。

為什麼只跟鄰居通

節點不一跳就連到所有節點，只跟附近的通，原因有二：

• 無線通訊耗電，能量隨無線範圍的平方上升。
• 縮短範圍可減少網路競爭。

兩個例子與易變性來源

• 森林防火：節點散布森林，量溫度、聲音、光；靠電池、短距 peer-to-peer 通訊。易變性來自節點因電池耗盡或火災等意外故障，連線也隨環境變化。
• 車載交通監測：節點裝在車上監測路況，經過的車輛接力傳遞，警告下游駕駛。易變性主要來自節點移動快速改變連線——這是行動 ad hoc 網路 (MANET)。

通常還有一個更強的 root node，負責長距通訊把警報傳給會反應的傳統系統（如火災時通報緊急服務）。

生活妙喻

通訊比運算貴，所以『能算就別傳』

節能驅動的三大架構特徵

只把感測網路當成傳統網路（分網路層與上層）會有問題：傳統的調適路由未必省能，且易變性破壞了上層的許多假設。從第一原理出發，兩大需求——節能與容忍易變下的持續運作——導出三大架構特徵。

特徵一：網內處理 (in-network processing)

通訊不僅絕對耗能，相對於運算更貴。Pottie 與 Kaiser 算出：用同樣的能量（3J），通用處理器可執行 300 萬條指令，卻只夠把 1 kbit 資料用無線傳 100 公尺。

所以一般而言運算優於通訊：花點 CPU 判斷『現在到底需不需要傳』，比盲目把感測值全傳出去划算。這就是為何感測節點要有運算能力。

網內處理指在節點上處理：聚合或平均鄰近節點的值（看一塊區域而非單點）、過濾無用或重複資料、偵測警報、依感測值開關感測器。例如低功耗光感測器若偵測到陰影（可能有動物），鄰近節點才打開高功耗麥克風去聽動物聲，其餘時間關著省電。

把它想成：與其打長途電話報告每件小事，不如在當地先想清楚、整理好，真有要事才打一通。

實用超能力

容斷網路與資料導向：directed diffusion

特徵二：容斷網路 (disruption-tolerant networking)

易變系統可能沒有持續存在的端到端路徑。容斷／容延網路用機會式通訊：資料能傳就傳，節點以儲存轉發 (store-and-forward) 接力，直到達成端到端目標。傳輸單位叫 bundle，含應用資料與處理指示；交棒後，接手的節點負責下一跳，資源差的節點交棒後就能釋放儲存。也可冗餘地多送幾個鄰居以防失敗。

特徵三：資料導向程式設計（directed diffusion）

資料導向技術消除節點身分——任何依賴特定節點持續存在的程式在易變系統都不可靠。

flowchart TD
  A[sink 節點注入 interest 任務宣告] --> B[interest 在網路中擴散]
  B --> C[每個收到的節點記錄並繼續傳播]
  C --> D[source 節點以特性符合 interest]
  D --> E[資料沿 gradient 反向流回 sink]

在 directed diffusion 中：

• 程式設計師指定 interest（興趣）——注入在 sink（匯點） 的任務宣告，含屬性-值對，這些就是要執行任務的節點的『名字』。
• interest 從 sink 擴散 (diffusion) 出去；收到的節點記錄它與回傳路徑資訊，再繼續傳播。
• source（源點） 是特性符合 interest 的節點（如裝了適當感測器），它開感測器產生 sink 要的資料。
• 資料沿 gradient（梯度，方向-值對） 反向流回 sink；gradient 的值可控制流速。
• 程式設計師還能放 filter 在節點上攔截通過的資料（如抑制不同節點對同一動物的重複警報）。

關鍵：節點不靠身分指名，而是靠它具備什麼特性來指名。另一種資料導向法是分散式查詢處理，用類 SQL 語言下查詢、由節點集體執行。

深度探秘

自我定位 vs. 被追蹤，是隱私的關鍵分水嶺

定位最受關注

在普及運算的各種感測中，定位 (location sensing) 最受重視。位置是行動、情境感知運算的明顯參數，也能用於導航、依地理決定網路路由等。

一個與隱私攸關的重要區別

自我定位 vs. 被追蹤：物件／使用者自己決定其位置，還是別的東西決定它的位置？後者稱為追蹤 (tracking)。

這個區別對隱私至關重要：

• GPS：絕對隱私。運作過程中，沒有任何關於接收裝置的資訊被傳出去——是你自己算出自己在哪。
• 無線信標 (radio beaconing)：可保有隱私，但視用法而定。若裝置只聆聽信標、從不與基礎建設通訊，就保有隱私。
• 追蹤技術（Active Bat、UWB、Active Badge、自動識別標籤）：每次都把識別碼交給基礎建設，等於告訴它『某人某時在某已知位置』，即使不報身分也可能被推斷。
• Easy Living（視覺）：靠辨識使用者來定位，身分揭露最直接。

各技術的機制也決定了限制（室內外、需要哪些安裝）與精度等級。

生活妙喻

GPS 像聽好幾個廣播塔報時來算自己在哪

幾種定位技術

GPS 怎麼算

GPS 用約 24 顆繞地衛星。每顆廣播原子鐘的現在時間與自己的位置資訊。接收器用訊號到達時間與發送時間之差乘上電波速度，算出它與各可見衛星的距離，再用三角學的多點定位 (multilateration) 算出位置。

比喻：像同時聽好幾座廣播塔報時，由『各塔聲音傳到我這的時間差』反推我站在哪。至少要看到 3 顆衛星才能算經緯度，更多顆才能算高度。

無線信標則只給鄰近性：若信標位置已知，目標就在信標的無線範圍內；要絕對位置還得查識別碼對應位置的資料庫。

實用超能力

實體位置 vs. 語意位置：經緯度 vs.『101 房』

Active Bat：用無線＋超音波

Active Bat 用於室內相對定位，精度約 10 cm：

flowchart TD
  A[基地台同時送 無線信號給 bat 與 有線信號給天花板接收器] --> B[bat 收到無線信號立即發出超音波脈衝]
  A --> C[天花板接收器收到有線信號同時啟動計時器]
  B --> D[接收器收到超音波脈衝讀取飛行時間]
  C --> D
  D --> E[基地台用聲速與至少三個非共線距離算出 bat 的 3D 位置]

利用電磁波遠快於聲速，計時器啟動與超音波發出近乎同時；由飛行時間換算距離，至少三個非共線接收器即可算出 3D 位置。UWB 則用極窄脈衝精準測飛行時間（約 15 cm），且訊號能穿牆、低功耗。

實體位置 vs. 語意位置

• 實體位置 (physical location)：空間座標（如經緯度 51° 27.010 N, 002° 37.107 W）。好處是能連到 GIS、世界模型算距離、關聯資訊；但維護資料庫成本高。
• 語意位置 (semantic location)：位置的名稱或描述。如 Active Badge 被『101 房』的紅外線讀到，就知道它在『Room 101』。對人類直覺友善，但不直接告訴你空間座標。

經緯度方便算距離卻難讓人理解；『101 房』讓人秒懂卻不利計算——兩者各有用途。無線信標可提供語意或實體位置（看用法）。

深度探秘

信任被降低，隱私被威脅

兩條主軸

易變系統給安全與隱私帶來新問題：

1. 安全：使用者與管理員要保護資料與資源（機密性、完整性、可用性）。但信任——所有安全的基礎——常被降低：能自發互通的主體間可能毫無先前認識，也無共同的可信第三方。
2. 隱私：隱私大致是『控制關於自己的資訊可被存取的能力』。但因為使用者經過的智慧空間裡到處有感測，隱私比以往更受威脅。

還得『輕量』

更麻煩的是：安全與隱私的措施必須輕量——

• 部分是為了保住互動的自發性；
• 部分是因為許多裝置的使用者介面很受限。

你不會想在用主人辦公室的智慧筆之前，還得先『登入』那支筆吧！所以打帳號密碼那套在這裡常常行不通。

生活妙喻

小裝置容易被偷，還會被『熬夜整』到沒電

硬體相關問題

傳統安全協定對裝置與連線的假設常不成立：

• 容易被偷被竄改：smart phone、感測節點比鎖在房裡的 PC 更容易被偷被動手腳。設計不該依賴任何可能被攻陷的裝置子集的完整性。一招是讓攻擊者得同時拜訪許多地點才能成功。
• 算不動公鑰密碼：很多裝置連橢圓曲線密碼都吃力。SPINS 只用對稱式金鑰（低功耗裝置才跑得動），但又衍生『哪些節點該共用同把金鑰』的難題——全共用則一台被攻陷全垮，各自不同把則金鑰太多存不下；折衷是只與最近鄰居共用、逐跳加密。
• 能量是新攻擊面：睡眠剝奪攻擊 (sleep deprivation torture attack)——攻擊者狂送無用訊息，讓裝置在接收上耗光電池；或偷偷給裝置會耗能的程式碼或資料（如看似靜止其實一直重繪的動畫 GIF）。
• 斷線運作：最好別用需持續連伺服器的協定。例如巴士乘客在休息站免費取飲料，與其每次連總部驗證，不如給使用者裝置一張憑證，讓販賣機用 Bluetooth 就近驗證。但離線就無法撤銷憑證，只能設到期，又衍生『離線裝置如何保有準確時間』的問題。

把睡眠剝奪攻擊想成『不斷打電話吵你、讓你整夜沒法睡，最後累垮』——對靠電池的小裝置，這就是耗光電力。

實用超能力

自發資源分享帶來的新安全情境

三個新型資源分享範例

易變系統催生了傳統防火牆內網或開放網際網路上沒見過的資源分享型態：

flowchart TD
  A[新型自發資源分享] --> B[訪客用研討室投影或咖啡廳印表機]
  A --> C[兩位同事在研討會用手機互傳文件]
  A --> D[護理師把心率監測器接到某病患的紀錄服務]

1. 訪客用空間服務：投影服務或印表機只給訪客用，但無線網路可能延伸到建築外，攻擊者可竊聽、干擾簡報、送假列印工作。需要保護，但打帳密登入太費事，使用者也可能有隱私顧慮。
2. 同事互傳文件：像在公司內網寄 email，卻發生在滿是陌生人的公共無線網路。可信第三方（公司）原則上存在，實務上卻可能連不上或沒設定在裝置裡。
3. 護理師接心率監測器：她暫時且安全地『借用』一台可信裝置（像訪客借投影機），但這例子更凸顯重複使用問題——一堆相似感測器在不同時間給不同病患用，必須安全地建立與解除裝置與病患紀錄的關聯。

共同點：每個都是自發互通，都引發安全與隱私問題，且都不像傳統防火牆內網或開放網路那套既有模式。

深度探秘

用『物理證據』而非『密碼證據』建立安全

安全自發裝置關聯

安全自發裝置關聯 (secure spontaneous device association)（又稱 secure transient association）的目標：在無線網路 W 上的兩裝置間建立安全通道——安全交換一把 session key 並用它加密 W 上的通訊。

起始假設很苛刻：因為是自發的，兩裝置不共享秘密、不持有對方公鑰、也無可信第三方；攻擊者能竊聽 W、重放與合成訊息，甚至發動中間人攻擊。

關鍵洞見：光靠 W 上的通訊無法安全交換金鑰，必須有頻外 (out-of-band) 通訊。

本章的安全技術大幅偏離標準做法：它們利用『系統整合於實體世界』這點，用物理證據而非密碼證據來建立安全性。

Bluetooth 標準做法是讓使用者在一裝置選的數字字串、到另一裝置輸入，但常用 0000 這種短字串，攻擊者可窮舉破解。

生活妙喻

受限通道像『只在這個房間裡才聽得到的悄悄話』

受實體限制的通道（側通道）

用受實體限制的通道 (physically constrained channel)——傳播在角度、範圍或時間上受限的側通道——可推斷收發者的物理性質。三種用法：

1. 接收受限通道：一裝置產生新 session key，透過『限制誰收得到』的通道送給對方。技術包括：
   • physical contact：兩裝置直接電氣接觸（圖 19.10）。
   • Infrared：紅外線可做到約 60 度方向性、被牆窗衰減，約 1 公尺內『beam』金鑰。
   • Audio：用房內輕柔音樂的調變傳資料，幾乎不出房間。
   • Laser：把窄雷射光束點到對方接收器，精度更高。
   • Barcode 與相機：一裝置把金鑰顯示成條碼，另一裝置用相機讀。
2. 發送受限通道：用受限通道認證一裝置送出的公鑰，再用標準協定交換 session key（需算得動公鑰）。
3. 先樂觀交換再驗證：先（可能不安全地）交換金鑰，再用受限通道驗證金鑰確實只被正確的物理來源持有；驗證失敗就重來。

flowchart TD
  A[兩裝置以物理接觸交換新秘密金鑰 K] --> B[之後在無線 W 上用 K 建立安全通道溝通]

把這想成『只在這個房間裡才聽得到的悄悄話』——出了房間，攻擊者就接收不到（或要極大代價）。當然，這類通道只提供有限安全：夠靈敏的接收器仍可能竊聽，但日常用途下通常夠好。

實用超能力

復活小鴨、基於位置的認證，與隱私保護

復活小鴨協定 (resurrecting duckling)

處理『同一裝置在病患間重複關聯』的問題。名稱來自小鴨會把第一眼看到的當媽媽（imprinting）：

• 『小鴨』裝置一開始處於可印記狀態，與第一個關聯它的『媽媽』裝置交換秘密金鑰，之後拒絕其他不知道金鑰的主體。
• 要重新關聯，得先『殺死小鴨的靈魂』——媽媽命令它回到可印記狀態，記憶被安全清除，之後才能被下一台裝置控制。

基於位置的認證

管理員需要存取控制：只有實際在空間裡的人能用服務。但認證身分常不妥（隱私顧慮、訪客流動）。解法：依客戶端的位置而非身分授權。用一個瀰漫整個空間卻不出界的受限通道（如咖啡廳音樂、會議室紅外線），加上一個空間內、服務信任的位置認證代理，透過 web 重導讓裝置取得『我真的在這裡』的證明再轉給服務。

隱私保護

flowchart TD
  A[使用者洩漏的識別碼來源] --> B[服務中提供的名稱位址]
  A --> C[Bluetooth 802.11 的固定 MAC 位址]
  A --> D[RFID 標籤 全域唯一]
  B --> E[可關聯到位置與活動 進而連到個人資訊]
  C --> E
  D --> E

• 化名 vs. 匿名：匿名識別碼每次請求都隨機換；化名 (pseudonym) 是同一客戶在一段時間內一致使用的假名，好處是能累積信任或聲譽而不揭真實身分。
• 隱私代理 (privacy proxy)：使用者信任它，替所有請求換上匿名或化名識別碼；但它是單點弱點，且無法隱藏使用者存取了哪些服務（仍可被流量分析）。
• 混合 (mixing)：把多人通訊混在一起，讓攻擊者難以分辨誰是誰。可建匿名代理的疊加網路，也可用混合區 (mix zones)（如走廊）——使用者在不存取定位服務的區域更換化名，達到類似匿名網路的效果。

深度探秘

裝置差異大到好幾個數量級，內容得『因地制宜』

為什麼要調適

易變系統的裝置在處理能力、I/O（如螢幕大小）、頻寬、記憶體、能量上比 PC 異質得多，最窮與最富的裝置可能差好幾個數量級，且這不會明顯改善。再加上頻寬、能量等執行時條件會劇變——所以需要調適系統 (adaptive systems)：依當前資源狀況調整執行時行為。

情境感知的內容調適

最簡單的做法是『內容生產者送一樣的內容，由消費裝置自行渲染』——有時可行（內容夠抽象時），但一般行不通：螢幕大小不一（有些根本沒螢幕）、I/O 軟硬體不齊、可能缺特定編碼的軟體或資源不足、或頻寬太低送不過去。

更進一步：要送什麼內容是情境的函數——不只看裝置能力，還看使用者偏好（有人偏好文字勝過圖、偏好語音勝過視覺）與使用者任務（同一張地圖，給遊客看景點、給維修工看基礎設施接入點，內容該不同）。

手工為每種情境量身打造太費事，於是程式化地調適原始資料：從中選取、生成或轉換。若原始資料與呈現方式分離（如 XML），可用 XSLT 產生對應形式；若原始資料已是多媒體（如影像），調適過程稱為 transcoding（轉碼）。調適可在媒體類型內（如降影像解析度）或跨類型（如文字轉語音）進行。

生活妙喻

在資源充足的『中介站』先把內容改好再送

Web 模型：調適放在資源充足的基礎建設

Web 的做法是讓調適發生在資源充足的基礎建設（服務本身或 proxy），而非資源貧乏的客戶端。HTTP 有種內容協商 (content negotiation)：客戶端在請求標頭表明能接受的 MIME 型別偏好，伺服器盡量配合。但這對情境感知調適太有限（能指定影像編碼，卻沒法說螢幕大小）。

於是 W3C 與 OMA 發展出 CC/PP（Composite Capabilities/Preferences Profile） 等標準，讓裝置詳細描述能力與設定（螢幕大小、頻寬）。這檔案可大到 10 KB 以上，太耗頻寬與能量，所以手機只在請求標頭送 profile 的 URI，伺服器去抓並快取。

型別專屬壓縮：Fox 等人的 proxy 架構

flowchart TD
  S[服務 內容來源] --> P[Proxy 即時壓縮轉碼]
  P --> C[資源貧乏的客戶端]

他們主張三大特徵：

• 壓縮應有損但針對媒體型別，用語意資訊決定保留哪些特徵（如影像可丟掉色彩資訊）。
• 轉碼應即時 (on the fly)——靜態預備的內容形式無法應付動態資料與越來越多的 client／服務排列組合。
• 轉碼應放在 proxy 上，讓 client 與服務都透明地與轉碼無關，且運算密集的轉碼可跑在可擴充硬體上。

把 proxy 想成一個中介站：在資源充足的地方先把內容改成適合你裝置的樣子，再送給你，省得你的小裝置自己硬扛。

但到了智慧空間，要重新檢視假設：調適可能發生在任意一對動態關聯的裝置間，提供者可能也太弱而做不了某些調適——一是讓智慧空間在基礎建設提供調適 proxy，二是檢視哪些調適（尤其壓縮）能在小裝置上做。即使有強大 proxy，裝置仍得把資料送過去；理論上傳前壓縮較省能，但壓縮的記憶體存取模式對耗能影響很大，需仔細最佳化。

實用超能力

對變動資源調適：Odyssey 與 cyber foraging

OS 對變動資源的調適：Odyssey

Satyanarayanan 提出三種調適法：(1) 應用請求資源預留（但在能量耗盡等情況難保證）；(2) 通知使用者資源變化讓他自己反應（如手動調影片畫質）；(3) OS 通知應用資源變化，由應用依需求自行調適。

Odyssey 走第三條路：應用管理影片、影像等資料型別，隨資源變化調整保真度 (fidelity)——型別專屬的品質。一個叫 viceroy 的元件把裝置總資源分給各應用。每個應用有個容忍視窗 (window of tolerance)：一段資源水準區間，寬到貼近真實變動、又窄到讓應用在其中行為大致一致。當 viceroy 必須把資源變到視窗外，它對應用發出 upcall，應用就反應（如影片在頻寬極低時轉黑白，其上則平滑調整幀率／解析度）。

借用智慧空間資源：cyber foraging

cyber foraging（網路覓食） 是讓處理能力受限的裝置，在智慧空間裡發現一台計算伺服器並把部分運算卸載 (offload) 給它。例如語音轉文字很吃運算，可交給市電供電、處理力強上許多的伺服器。兩個目的：提升回應速度與省電（把工作丟給插電的伺服器）。

flowchart TD
  A[處理受限的行動裝置] --> B[在智慧空間發現計算伺服器]
  B --> C[把部分運算卸載給它]
  C --> D[提升回應速度並節省電池]
  D --> E[但通訊也耗能 需確保整體真的省電]

挑戰：應用要能拆解到一部分能在伺服器跑、但沒伺服器時仍能（較慢或較低保真）正常運作；卸載的部分應通訊量少，否則低頻寬下通訊時間反而吃掉處理增益；而且通訊本身耗能，不保證一定省電——得仔細權衡。

深度探秘

Cooltown 的核心理念：『每樣東西都有網頁』

Cooltown 是什麼

HP 的 Cooltown 專案目標是為遊牧運算 (nomadic computing)——以人為中心的行動與普及運算——提供基礎建設。『遊牧』指人在家、工作場所、商店間移動；『運算』指提供給這些移動使用者、且與實體世界中的實體整合的服務。使用者帶著或穿著有無線、有感測器的裝置（當年多為 PDA）。

把 Web 的成功延伸到實體世界

專案的核心是把 Web 的兩個成功經驗用到遊牧運算：

1. 『每樣東西都有網頁』：每個實體世界的實體（不管是不是電子的）都有一個關聯的 web 資源叫 web presence，使用者在該實體面前就能方便存取。web presence 可以只是含資訊的網頁，也可以是任何與該實體關聯的服務（如某產品的『取得替換零件』服務）。
2. 高度互通性：遊牧使用者可能在從沒去過的地方、與從沒遇過的 web presence 互動，不應要他們在裝置上載新軟體或重設定。

本節聚焦三件事：web presences、physical hyperlinks（實體超連結）、與 eSquirt 互通協定。

生活妙喻

人、地、物各有名片，地方收集所有名片

人、地、物三類

Cooltown 把實體分成人 (people)、地 (places)、物 (things)，各有 web presence：

物與人的 web presence 被收集在地的 web presence 裡，所以介紹順序是物 → 人 → 地。

地方怎麼收集名片

地點目錄的登記有兩種方式：

• 網路探索服務自動登記由子網路內裝置實作的 web presence（無線連入的裝置或基礎建設伺服器）。
• 但非電子實體（人、印刷文件、音樂 CD）的 web presence 可能託管在任何地方，得手動或經感測登記——這叫physical registration（實體註冊），例如感測它們的 RFID 標籤。

一個叫 web presence manager 的服務管理這些 web-present 的地、人、物，並把每個實體連到其情境中相關實體的 web presence。

實用超能力

實體超連結：直接感測 vs. 間接感測

什麼是實體超連結

web presence 是普通 web 資源，網頁當然能用文字或圖片連結它。但 Cooltown 還讓人能從實體來源直接跳到 web presence——也就是從你在現實中遇到的那個人、地、物。

physical hyperlink（實體超連結） 是讓使用者能從實體本身或其周遭取得其 web presence 的 URL 的任何手段。例如在博物館想『點一下』畫作來在手機上看介紹——把 URL 寫在牆上要人手打太笨拙，於是用裝置上的感測器。兩種方法：

flowchart TD
  A[使用者裝置靠近實體] --> B{感測方式}
  B -->|直接感測| C[從標籤或信標直接讀到 URL]
  B -->|間接感測| D[讀到識別碼]
  D --> E[送到 resolver 名稱伺服器]
  E --> F[resolver 回傳對應的 URL]
  C --> G[瀏覽器前往該 URL]
  F --> G

• 直接感測 (direct sensing)：裝置從附在實體上的標籤或信標直接讀到 URL。Cooltown 的信標是幾公分大的小裝置，每隔幾秒用紅外線、一次性無連線協定發出一段含 URL 與短標題的字串；當年很多手機、PDA 都有紅外線收發器收得到。
• 間接感測 (indirect sensing)：裝置讀到一個識別碼，再經 resolver（解析器，一種名稱伺服器） 查出 URL。

為何需要間接感測

有時因標籤技術限制（線性條碼容量不足、便宜 RFID 只存固定長度識別碼）只能間接。但間接還有正面理由：同一實體可有多個 web presence——換不同 resolver 就得到不同 web presence（如一個指向館內列印服務，另一個指向第三方的畫作解說頁）。

代價：間接感測要多一次往返 resolver，增加延遲與耗能。

深度探秘

先看標準 web 互通的問題

標準 web 互通：裝置卡在內容路徑上

一種裝置互通法是用標準 web 協定：你的可攜裝置對 web-present 的目標裝置發 HTTP GET 或 POST，目標回傳一個網頁形式的 UI，由你的裝置渲染。

例如 Internet radio 用信標對外發出其 web 服務的 URL，你把 PDA 紅外線對準它接收 URL，radio 的『首頁』就出現在 PDA 上，可調音量、上傳播放聲音檔。博物館的 web-present 印表機也類似：取得首頁後上傳內容、設定列印選項。這種互通是資料導向、裝置無關的（目標裝置自帶 UI，你不需專屬軟體）。

問題：低保真

但有個麻煩：你資源貧乏、可能低頻寬的可攜裝置，卡在內容的來源與接收端之間。

假設你在博物館取得一張畫作影像或一段語音解說，因為螢幕與頻寬受限，可能已被調適成低保真版本。當你把它傳給博物館印表機或飯店房間的 Internet radio——那些裝置明明能高品質呈現、也可能有高頻寬有線連線——卻只拿到低品質版本。

生活妙喻

eSquirt：只傳『地址』而不傳『包裹』

eSquirt 的關鍵點子

Cooltown 的 eSquirt 協定解決低保真問題（也省下寶貴的頻寬與能量）：它只傳內容的 URL，而不傳內容本身。事實上，這協定和『從 Cooltown 信標把 URL 與標題用紅外線送到裝置』用的是同一個。

flowchart TD
  A[使用者從畫作旁信標取得影像 URL] --> B[用 eSquirt 把 URL 用紅外線送到印表機]
  B --> C[印表機當作 web client 用該 URL 抓取全保真內容]
  C --> D[印表機印出高品質影像]

裝置只透過低能量的紅外線傳這一小段資料，這是 eSquirt 本身唯一的網路操作；接收裝置接著當作 web client 用 URL 去抓全保真內容並處理（如列印）。eSquirt 是不可靠的，但就像電視遙控器——傳輸失敗就再按一次『squirt』，直到接收端回饋成功。

把它想成只給對方地址而不扛整個包裹過去：你把『東西在哪』告訴印表機，讓印表機自己去（用它的高速連線）把高品質的原件取回來印。

因此可攜裝置就像一個裝置無關的 URL 剪貼簿：你用它在來源與接收端之間『複製貼上』URL 來搬移內容。

實用超能力

eSquirt 的優缺點，與『人在迴路中』的整體評價

eSquirt 的優點與缺點

• 最大優點：裝置無關。eSquirt 永遠用同一種方式運作，不同的只是接收端對 URL 的處理。使用者用同一支裝置就能把 URL 送給印表機、相框、Internet radio、HiFi 等。
• 設計上故意不防呆：使用者得自己判斷什麼組合合理（把音檔 URL squirt 給印表機就是錯）。但不該事先設計掉這些錯誤——加型別檢查反而會帶來『失去的機會』與『脆弱互通』（你在 19.2.2 學過）。
• 缺點：靠預設設定。eSquirt 不提供『由 client 取得虛擬 UI 來控制目標裝置設定』那種互通。例如把電台 URL squirt 給 Internet radio 後，要怎麼從可攜裝置控制音量？只能靠接收裝置的預設或實體控制。

整體評價：人很『在迴路中』

Cooltown 大致達成目標，但前提是人很在迴路中 (human in the loop)：

• 人實體地發現實體關聯的服務（透過實體超連結）。
• 人可能要實體註冊被標記的非電子實體（如把音樂 CD 放進 web-present 的家）。
• 人不只靠『點』實體超連結來關聯，還透過 eSquirt 促成裝置無關的互通。

人介入帶來極大彈性、也消除了『失去的機會』問題；但簡單的 eSquirt 模型不給使用者控制接收裝置拿 URL 後做什麼。

另一條發展方向是自動化關聯與互通：每個實體有統一型別的 web presence，記錄其語意與關聯（如人／物與所在地的關係），讓同一地方的 web presence 能互相發現並互通（如祕書的 web presence 自動找到要印的文件、在場成員、附近印表機並印好）。但現實世界語意複雜，這類自動化離實用仍遠；在那之前，把人放進迴路中讓進展得以發生。