中華大學

(1)

中華大學碩士論文

通用型隨插即用跨網際網路資源分享技術之研究

Study on UPnP Resource Sharing over the Internet

系所別：資訊工程學系碩士班學號姓名： M09702046 謝承佑指導教授：劉懷仁博士

中華民國 101 年 2 月

(2)

i

摘要

隨時網際網路的普及，數位家庭將是未來值得大家探討的一個議題。在數位家庭網路中，許多消費型電子產品廣泛使用通用型隨插即用協定，不同品牌的設備不需要多餘的設定，即可互相運作使用，讓使用者透過有線或無線的傳輸方式來播放電腦中的檔案。

通用型隨插即用協定設備以廣播封包通知它們的服務，在路由器不提供轉送廣播封包的情況下，通用型隨插即用協定只能在區域網路環境使用。本篇論文提出通用型隨插即用協定跨網際網路分享，通用型隨插即用設備可以透過伺服器建立一個虛擬區域網路，由於資訊安全的需求，可以限制資源僅能分享給同一個虛擬區域網路，接著實作這個概念，從實驗結果可以看到封包的耗費時間幾乎沒有增加，本篇論文提出一種可行的檔案分享方式。

關鍵字: 內容分享、通用型隨插即用協定、數位家庭多媒體網路

(3)

ii

ABSTRACT

As the Internet becomes a part of people’s lives, digital home networking becomes important research topic in the future. In digital home networking, many consumer electronics use UPnP protocol. Even though they are products of different manufactures, they can auto-configure and co-operate with each other. For example, a user can use any media player to play media files from media servers in wired or wireless networks.

UPnP devices advertise their services by multicasting UPnP messages. Because the current routers do not route any multicast datagram, UPnP multicast messages are broadcast only within a local area network. In this thesis, the topic of UPnP resource sharing over the Internet is studied. Due to the security requirement, many UPnP devices can logically connect as a virtual LAN by VLAN server, but UPnP devices of different VLANs will not share their resources with each other. The concept was implemented and experimental results show that the proposed method will add little overhead such that the proposed method can be considered to be an alternative to this research topic.

Keywords : Content Sharing, UPnP, DLNA

(4)

iii

致謝

首先感謝我的指導教授劉懷仁博士在我求學期間的指導，在我有疑問時提供意見，讓我有一個明確的目標，使我從中學習並提升解決問題的能力。

感謝實驗室的同學們，在學業上可以互相討論，在生活中可以互相幫忙，讓我在一個很好的環境中學習。

感謝我的家人在這段時間給予我的支持，讓我能專心的做研究，而順利完成學業，也感謝其他幫助過我的朋友。

(5)

iv

表目錄

表1. VPN通訊協定比較………..11 表2. UPnP網路環境比較……….………43 表3. UPnP耗時……….45

(7)

vi

圖目錄

圖1. UPnP通訊協定堆疊結構……….……..3

圖2. UPnP Device Architecture……….…………7

圖3. UPnP AV Device Architecture………..……….8

圖4. 播放架構………..……….9

圖5. Network Configuration of Extended Home Space………...………13

圖6. A/V Media Streaming Across NATed Homes……….……14

圖7. UPnP message over P2P network………..…………..16

圖8. MSEARCH message over P2P network……….…….17

圖9. NOTIFY message over P2P network………...…………17

圖10. Service acquiring message over P2P network………...…….18

圖11. Control message over P2P network………...…….19

圖12. Proposed Architecture………..…..20

圖13. The DLNA Proxy System (DPS) Architecture………..21

圖14. The Message Call Flows for the DPS………...…….22

圖15. Generic Architecture………..23

圖16. Sequence of Actions for Remote Discovery………..24

圖17. Sequence of Actions for Remote Announcements……….25

圖18. 個人化互聯網……….………..27

圖19. 使用流程圖………..………….28

圖20. 個人化群組清單……….……..29

圖21. 加入群組……….……..30

圖22. DLNA設備互動圖……….31

圖23. 區分群組示意圖………….……….……..33

(8)

vii

圖24. 網路介面………...……34

圖25. 建立群組之Start步驟……….…..35

圖26. 建立群組之Create account步驟……….………..36

圖27. 建立群組之Add new group步驟………..37

圖28. 建立群組之Create group步驟………..38

圖29. 建立群組之Select group步驟………..…….39

圖30. 建立群組之Add members步驟………..………..39

圖31. 建立群組之Select VLAN server步驟………..………40

圖32. 加入群組之Check invited status步驟………..…….41

圖33. 加入群組之VLAN server url步驟………42

圖34. 加入群組之Join VLAN server步驟……….43

圖35. DMS without ARP table……….44

圖36. DMS with ARP table………..45

圖37. 拓撲架構………...46

圖38. DMS分享的資料夾………...47

圖39. 檔案總管………...48

圖40. ipconfig in DMS……….49

圖41. ipconfig in DMP……….50

圖42. 播放清單………...51

圖43. 播放檔案中………...51

(9)

1

第一章簡介

現今大多的家庭都有網路，網路已成為日常生活中的一部份，透過網路將電腦、

立體聲喇叭，電視螢幕結合在一起，以往在需要播放影片時，使用者會準備 DVD/CD 光碟，到客廳/房間等不同地方使用 DVD player 播放，每當換一個場所，都需要攜帶光碟。在家庭網路的概念興起，使用者只需要將檔案儲存於媒體伺服器中，透過網路串流的方式，將檔案傳輸到媒體播放器上面播放，達到檔案分享[1]的便利性。

現在有越來越多的多媒體檔案存在於個人電腦中，使用者可以利用家庭網路，透過個人電腦、智慧型手機、平板電腦，等消費型電子產品播放數位內容，當使用者想從遠端觀看數位內容時，必須經過繁鎖的設定後才能使用。以傳統的檔案分享方式來說，檔案擁有者需要架設 FTP server，並且設定 FTP 通訊協定允許通過防火牆，而檔案使用者需要具備 FTP client 才能下載檔案，而檔案必須在下載完成後才能順利開啟。近期以來已經越來越多的使用者運用 Universal Plug and Play (UPnP)[2]達到檔案分享，由於 UPnP 使用 multicast 封包搜尋相關服務，在路由器不提供轉送 multicast 封包的情況下，標準的 UPnP 通訊協定僅能在同一個區域網路運作。因此，有相關研究提出多種方法[3]-[11]，達成透過網際網路分享檔案。為了解決 multicast 現在無法在網際網路轉送的問題，本論文使用了 Virtual Private Network(VPN)的機制來解決此一問題。本篇論文提出個人化互聯網，以不破壞產品之間的相容性為前提，使用現有的 UPnP 設備以及標準的 UPnP 通訊協定，利用 UPnP 的便利性，簡易達到使用者的目的。

本篇論文分成五章，第一章簡介家庭網路的應用與發展以及本篇論文的研究動機，第二章將介紹 UPnP 通訊協定背景知識以及相關研究，第三章提出系統架構，第四章提出實作畫面與實驗結果，第五章為本篇論文結論。

(10)

2

第二章背景知識與相關研究

UPnP 是由 UPnP Forum 推出的使用於網路的一種通訊協定[2]，現在常用在數位家庭網路，該協定希望在家庭網路裡面，設備之間能夠自己去做設定，不需要使用者安裝軟體、調整參數，設備可以通知其他設備自己的存在，透過這種方式，讓家電之間可以互連。UPnP 元件分成兩大類：Control Point、設備，Control Point 是搖控器，

負責控制設備，設備則是負責提供服務。當 Control Point 加入網路時，Control Point 使用 multicast solicitation 搜尋有興趣的設備；當設備加入網路時，會使用 multicast advertisement 告知自己的存在。為了使 Control Point(通常是搖控器或個人電腦)了解更多關於設備的資訊或者和設備進行互動，Control Point 會取得設備之 Description，

UPnP Description 使用 XML 格式，內容包括品牌、廠商相關資訊，如型號名和編號、

序列號、廠商名、品牌、相關 URL 等。當 Control Point 獲取到設備 Description 資訊之後，就可以向該設備發送 control action 指令了。當設備提供的服務或狀態資訊發生改變時，會回覆 event 通知 Control Point，而這些訊息也是採用 XML 格式。一般在使用上只需要透過 Control Point 輸入提供服務的設備 URL，透過瀏覽器連接 URL 後，

使用者就可以透過瀏覽器介面進行相關控制或檢視。

(11)

3

2.1 UPnP

2.1.1 UPnP 通訊協定堆疊結構

如圖 1 所示，為了相容於一般家庭網路環境，UPnP 廣泛使用現有的網路通訊協定。

UPnP Vendor UPnP Forum

UPnP Device Architecture

SSDP SOAP GENA

HTTPMU (multicast) HTTPU (unicast) HTTP HTTP

UDP TCP

IP

圖 1. UPnP 通訊協定堆疊結構

SSDP (Simple Service Discovery Protocol)

簡單服務發現協定(SSDP)是在 HTTPU 和 HTTPMU 的基礎上實作的協定。按照協定的規定，當一個 Control Point(用戶端)接入網路的時候，它可以向一個特定的 multicast 位址的 SSDP 埠使用 M-SEARCH 方法發送「ssdp:discover」訊息。當設備監聽到這個保留的 multicast 位址上由 Control Point 發送的訊息的時候，設備會分析 Control Point 請求的服務，如果自身提供了 Control Point 請求的服務，設備將透過

(12)

4

unicast 的方式直接回應 Control Point 的請求。

當一個設備接入網路的時候，它應當向一個特定的 multicast 位址的 SSDP 埠使用 NOTIFY 方法發送「ssdp:alive」訊息。Control Point 根據自己的策略，處理監聽到的訊息。考慮到設備可能在沒有通知的情況下停止服務或者從網路上移除，「ssdp:alive」

訊息必須在 HTTP 協定頭 CACHE-CONTROL 裡面指定超時值，設備必須在約定的超時值到達以前重發「ssdp:alive」訊息。如果 Control Point 在指定的超時值內沒有再次收到設備發送的「ssdp:alive」訊息，Control Point 將認為設備已經離線或關機。

當一個設備計劃從網路上移除的時候，它也應當向一個特定的 multicast 位址的 SSDP 埠使用 NOTIFY 方法發送「ssdp:byebye」訊息。但是，即使沒有發送「ssdp:byebye」

訊息，Control Point 也會根據「ssdp:alive」訊息指定的超時值，將超時並且沒有再次收到的「ssdp:alive」訊息對應的設備認為是離線或關機的設備。

在 IPv4 環境，當需要使用 multicast 方式傳送相關訊息的時候，SSDP 一般使用 multicast 位址 239.255.255.250 和 UDP 埠號 1900。

SOAP (Simple Object Access Protocol)

簡單物件存取協定(SOAP)是一種標準化的通訊規範，主要用於 Web 服務（web service）中。SOAP 的出現是為了簡化網頁伺服器（Web Server）在從 XML 數據庫中提取資料時，無需花時間去格式化頁面，並能夠讓不同應用程式之間透過 HTTP 通訊協定，以 XML 格式互相交換彼此的資料。在 UPnP 中，當 Control Point 獲取到設備 Description 資訊之後，即可向該設備發送 control action 指令。

GENA (General Event Notification Architecture)

一般事件通知架構(GENA)主要使用 HTTP 通訊協定傳送通知，在 UPnP 中，使

(13)

5

用 GENA 格式表示服務狀態，當 Control Point 希望接收到事件通知時，會傳送訂閱訊息，其中包括有興趣的服務，事件通知的訂閱時間，以及定期訂閱更新，也可以使用 GENA 取消訂閱。

HTTPU

HTTPU 協議是指在 UDP 基礎上實現通常在 TCP 上傳送的 HTTP 協議。HTTPU 協議被主要運用在 UPnP 協議的 SSDP 協議。

2.1.2 UPnP 運作流程分成六個階段

0. Addressing

所有的設備取得主機位址，可能是動態分配 IP 位址，或是固定 IP 位址，所有設備都會有 IP 位址，UPnP 可以使用 auto-configuration protocols 讓用戶端不需要做各種參數的設定，網路就能連線。

1. Discovery

如前 SSDP 章節所述，一種是 Control Point 使用 Solicitation 去搜尋有那些設備的存在，設備收到 Request 後，就會回應 Reply，另一種是設備使用 Advertisement 主動通知網路上其他 Control Point。

(14)

6

2. Description

Description 用 XML 描述，Control Point 使用 Get Description 找出設備對應的服務，設備把可以提供的服務資訊回傳給 Control Point。

3. Control

如前 SOAP 章節所述，Control Point 控制設備的功能、使用 Action 對設備下命令，

針對設備提供的服務出調整，設備執行結果使用 Action Result 回報給 Control Point。

4. Events

如前 GENA 章節所述，Control Point 監控網路的設備服務的狀態，Control Point 使用 Subscibe 向設備訂閱，當設備狀態發生改變時，設備會使用 Notify 通知 Control Point。

5. Presentation

Control Point 提供一個使用者介面(例如網頁瀏覽器)，Control Point 透過 Get Presentation 去控制其他設備的功能。

2.1.3 UPnP AV Architecture [12]

如圖 2 所示，在傳統的 UPnP Device Architecture[2]中，大多數（非 UPnP AV Architecture）的 UPnP 的情況下，Control Point 控制 UPnP 設備，各個設備不直接與

(15)

7

其他的設備互動。所有的設備的協調執行都由 Control Point 而不是設備本身。

圖 2. UPnP Device Architecture

如圖 3 所示，在 UPnP AV Architecture 中，大部分的情境涉及多媒體內容（即電影，歌曲，圖片等）從一個設備傳送到另一個設備，一個 Control Point 與兩個或兩個以上的 UPnP 設備互動，UPnP AV Architecture 使用 Out-of-Band Transfer Protocol，能夠傳輸內容，讓這些內容在各項設備之間自動傳送，而不需要經過 Control Point。

(16)

8

圖 3. UPnP AV Device Architecture

如圖 4 所示，最常見 UPnP AV Device Architecture 的情境就是使用者要在 Media Renderer 播放特定內容，環境中包含三個部份，Control Point、Media Server、Media Renderer，在這種情況下，Media Server 包含多媒體的內容，使用者希望透過 Media Renderer 來呈現多媒體的內容。使用者透過 Control Point 的介面查詢並選擇所需的內容的 Media Server 和選擇播放目標的 Media Renderer。

(17)

9

圖 4. 播放架構

Media Server 包含各種的內容，使用者可以查詢 Media Server 的內容，並使用網路通訊協定把檔案傳輸到另一個設備，檔案內容包括影片、音樂、圖片等等。

Media Renderer 透過網路從 Media Server 獲得內容，Media Renderer 包括電視，

音響，揚聲器等設備，不同的 Media Renderer 能播放不同檔案格式的內容，有些 Media Renderer 可能僅支持一種類型的圖片，有些 Media Renderer 可以支持各種各樣的內容包括影片、音樂、圖片。

Control Point 負責管理 Media Server 和 Media Renderer 的運作，如播放、停止、

暫停，Control Point 通常會提供一個介面或是一個手持搖控器供使用者使用。

(18)

10

2.2 Digital Living Network Alliance(DLNA)[13]

DLNA 是由多家消費型電子廠商組成的聯盟組織，該組織的目標在於建立一個標準的通訊協定，使各家廠商的產品互相連接，讓消費者操作上能夠輕鬆上手。DLNA 設備彼此之間使用前述之 UPnP 通訊協定互相交換資訊以完成彼此之運作關係。

DLNA 主要產品可分成 DMS 與 DMP 兩類，DMS 為儲存多媒體檔案的設備，相當於 UPnP 之 Media Server，DMP 為播放 DMS 提供的多媒體檔案的設備，相當於 UPnP 之 Media Renderer。

2.3multicast 網路傳輸模式

UPnP 設備使用 multicast 封包去搜尋相關的服務，multicast 是一對一個群組的傳輸模式，不同於 broadcast 的是，同一 subnet 中只有參加 multicast group 的主機才會收到封包，其他的主機就不會受到無謂的干擾。不管接收封包的主機有幾台，都只有一個資料流，也就是說，同一 subnet，不管接收主機的數量，所需的頻寬都是一樣的。

現行網際網路為降低網路負載與安全考量，路由器皆不提供轉送 multicast 封包之服務。

2.4 OpenVPN 簡介[14]

為了解決 multicast 現在無法在網際網路轉送的問題，本論文使用了 Virtual Private Network(VPN)的機制來解決此一問題，接下來介紹會使用到之相關技術 VPN。

OpenVPN 是一套免費的應用程式，利用 OpenVPN 可以創建一個虛擬專用網路加密通道，OpenVPN 提供了不同的驗證方式，用以確認參與連接雙方的身份，包括：

(19)

11

authentication certificate，以及用戶名／密碼組合來進行身份驗證。

OpenVPN 大量使用了 OpenSSL 加密庫中的 SSLv3/TLSv1 協議函數庫。目前 OpenVPN 能在主流作業系統上運行，並包含了許多安全性的功能。OpenVPN 使用 OpenSSL 庫加密數據與控制信息：它使用了 OpenSSL 的加密以及驗證功能，它能夠使用任何 OpenSSL 支持的演算法。

OpenVPN 可使用 TCP/UDP 通訊協定在 ISP 或企業公司過濾某些特定 VPN 協議的情況下。OpenVPN 連線能通過大多數的代理伺服器，也能夠在 NAT 的環境中執行。

client 端只需要知道 server 端的 IP 位址，就可以連線。這些 OpenVPN 的特點使它成為相較於 PPTP 或是 IPsec 等通訊協定的更好的選擇。此外，依網路狀況可在 Server 端設定，由於 UDP 為不可靠的傳輸機制，如有高延遲或者丟包較多的情況下，可以選擇 TCP 來代替 UDP。

為了讓 UPnP 訊息跨網際網路，本實驗使用 VLAN 的概念，將需要通訊的 UPnP 設備加入同一個 VLAN 當中，建置出 UPnP Network 環境，再來使用 VPN 技術完成實作，如表 1 所示，VPN 傳輸比較。

表 1. VPN 通訊協定比較

forwarding packet unicast multicast

PPTP support not support

OpenVPN support support

(20)

12

2.5 其它相關研究

Control Point 使用 multicast 去探索網路上可用的設備，由於 multicast 封包只能讓在同一 subnet 上所有主機收到封包訊息，無法任意跨越 router 傳遞，為了達到 UPnP 跨網際網路的資源分享，在保有 UPnP 通訊協定的情況下，必須解決 UPnP Discovery 封包的傳遞。為了解決 UPnP 跨網際網路的問題，先前有作者提出利用 Internet Gateway Device(IGD)[15][16]的解決方案，運行 IGD 必需要搭配 NAT router 的支援，

應用程式需要穿越 NAT router/gateway 使用，IGD 是一種常見的方法，用來自動配置 port forwarding，在沒有 IGD 的情況下，使用者需要人工進行配置 IP 位址與 port 的設定，過程耗時且容易出錯。

由於分別屬於兩個不同區域網路的 UPnP 設備無法直接連線彼此，在 PMCP[3][4]

的概念中，在網際網路上設計一個 relay peer 的元件，使不同區域網路的設備可以利用 relay peer 代為轉發 UPnP 訊息。JXTA 是一種通訊協定，它主要的功能是要讓網路上不同的結點做 P2P 的通訊，讓 UPnP 訊息可以穿過網際網路，與不同區域網路的 UPnP 設備溝通，如圖 5 所示，網際網路的兩端分別有兩個區域網路，這兩個區域網路透過 JXTA Protocol 與 UPnP IGD 通訊，一般我們家庭網路都有 IP 分享器，這個 IP 分享器主要的功能就是在做 NAT 的動作，使用者分別使用 private IP，但是共用同一個 public IP，那 IGD 主要的功能就是要把 public IP 的 port 做 port mapping 轉到 private IP 使用，兩個區域網路分別使用 UPnP Protocol，Media Server 在 Home A，Media Renderer 與使用者在 Home B，PMCP Server 與 PMCP Client 分別連接到 JXTA Relay Peer，此 Relay Peer 負責轉送 PMCP Server 與 PMCP Client 之間的的訊息，使 Home A 與 Home B 之間 UPnP 設備之間可以傳遞 discovery(SSDP)、Control(SOAP)訊息，最後，UPnP IGD 的新增一個 port mapping 讓檔案透過 media streaming 從 Media Server 傳給 media renderer 播放。

(21)

13

Internet

PCMP(Server)

UPnP IGD

PMCP(Client)

UPnP Media Renderer

UPnP IGD UPnP Media Server

Stream Data

Relay Peer JXTA Protocol

UPnP Protocol (SSDP, SOAP, etc)

JXTA Protocol

UPnP Protocol (SSDP, SOAP, etc)

Stream Data UPnP Protocol

(SSDP, SOAP, etc)

Stream Data

Home A Home B

圖 5. Network Configuration of Extended Home Space[3][4]

如圖 6 所示，此圖是介紹 media streaming 穿過 NAT 的流程，左右兩邊分別代表兩個區域網路，PMCP Server 與 PMCP Client 在各自的區域網路裡都是 Control Point，

PMCP Client 送出 M-Search 搜尋同一個網路的 Media Renderer 以及另一個區域網路的 PMCP Server ，PMCP Server 再做 M-Search 搜尋同一個區域網路的 IGD 與 Media Server，IGD 主要的功能就是在 NAT 的環境做 port mapping，Media Renderer 傳送 Notify 給 PMCP Client，PMCP Server 在收到 IGD 與 Media Server 的 Notify 後，會一併傳給 PMCP Client，因此，PMCP Client 可以得知 Media Server 與 IGD 這些設備的存在，

PMCP Client 會送出 Get Description 訊息，PCMP Client 可得到 Media Server 與 IGD 更多的細節包括像產品製造商、產品功能、服務清單相關訊息，再來使用者就可以用瀏覽 Media Server 的檔案清單，從 Get Protocol Info 步驟起，IGD 才會開始動作，PMCP Client 會傳送 Add port mapping 給 PMCP Server，再由 PMCP Server 傳送給 IGD 新增

(22)

14

port mapping 後，在 SetAVTransportURI 這個步驟，PMCP Client 會告知 Media Renderer 要播放檔案的路徑，並告知 Media Renderer 開始播放，此時，候檔案就可以以 media streaming 的方式從 Media Server 拉到 Media Renderer 播放，最後，當使用者欲關閉播放時，會從 PMCP Client 送出停止，PMCP Client 會通知 PMCP Server 再轉送 IGD 刪除 port mapping。

Media

Server IGD PMCP(Server) Internet

Media

Renderer PMCP(Client)

Home Network Remote UPnP Network

M-Search M-Search

IGD Notify MS Notify

MR Notify

Get Descriptions Get Descriptions

Browse Browse

Get Protocol Info AddPortMapping

SetAVTransportURI Play

Stop Out of Band Transfer Protocol

DeletePortMapping HTTP Get

圖 6. A/V Media Streaming Across NATed Homes[3][4]

透過 PMCP 架構，作者又提出一個延伸架構，使用的情境為，現在高畫質的檔案越來越大，如果檔案只有一個 Media Server 擁有，卻有很多 Media Renderer 要播放，

(23)

15

以傳統下載的方式會花費大量的頻寬與時間，所以作者提出一個 P2P 的概念，整合 UPnP 的架構，克服頻寬有限的問題。網際網路中有一個 Content Distributor 與多個 Content Collector，首先，使用者會選擇要播放的檔案，Content Distributor 會把該檔案從 Media Server 下載到 Content Distributor，再切格成多個子檔案，Content Distributor 向各個 Content Collector 傳送不同的區塊，這些 Content Collector 收到這些區塊後，

再轉送給其他 Content Collector，如此一來，每個 Content Collector 都可以擁有所有的區塊，Content Collector 再把這些區塊組成一個檔案，交給同一個區域網路的 Media Renderer 播放。

先前有作者設計利用 P2P[5]-[7]傳輸 UPnP message，以[5]為例，P2P 中的每一個 node 都具有 Middleware 可以處理 UPnP Device 的訊息以及網路傳輸的問題。如圖 7 所示，這篇論文利用 P2P 的方式，去佈署整個網路環境，此架構展示 UPnP message 從 Source 端傳送到 Destination 端的流程，每一個區域網路都具備 UPnP Middleware 與 P2P Middleware，UPnP message 從 Source 端送出後，封包經過 Intermediate 端，

Intermediate 端的 P2P Middleware 會去判斷這個 UPnP message 目的是否欲傳送到本地，若不是，UPnP Message 會往下一站傳送，當封包傳送到 Destination 端時，P2P Middleware 會確認此訊息是傳送到本地，封包在此時會傳送給 UPnP Middleware，最後讓 UPnP Device 收到訊息。

(24)

16

圖 7. UPnP message over P2P network[5]

如圖 8, 9 所示，實線代表 M-Search message，虛線代表 M-Search 的 response，

Control Point 在 Source 端送出 M-Search 後，中間的 node 會收到重複的訊息，為了解決這個問題，Intermediate 端設計一個機制去判斷之前有沒有收過重複的訊息，如果有就會自動忽略這個訊息，如果沒有就會轉送給下一個 node。當 UPnP Device 在 Source 端送出 NOTIFY 後，NOTIFY 也是一樣的概念，Intermediate 端會判斷訊息。

(25)

17

圖 8. MSEARCH message over P2P network[5]

圖 9. NOTIFY message over P2P network[5]

(26)

18

如圖 10, 11 所示，每個 node 都有 P2P middleware，這個 P2P middleware 有記錄臨近 node 的資訊，所以當要傳送這些訊息時，這個 P2P 架構就會自動去選擇適合的路徑傳輸，Control Point 欲取得更多 Device 的資訊時，實線的部份，會傳送 service acquiring message(Get Description)，虛線的部份，Device 再回覆 Control Point 訊息。

Control message 與 service acquiring 流程也是同樣的概念。

圖 10. Service acquiring message over P2P network[5]

(27)

19

圖 11. Control message over P2P network[5]

另外，有作者提出利用 UPnP Proxy[8]解決 UPnP 跨網際網路的問題，UPnP Proxy 為當使用者有網路資料要求時，Proxy Server 會幫使用者向目的地取得所需要的資料，內部區網無法直接從網路做資料存取，需要透過 Proxy Server 代理。

如圖 12 所示，private network A/B 的 proxy 直接連接，Control Point 設置在 private network A，UPnP Device 設置在 private network B，同一個 private network 的服務都是透過 OSGI 整合，另外，這個架構會對使用者的權限做區分，利用 Filter 過濾不同的使用者使用不同的 application。

(28)

20

圖 12. Proposed Architecture[8]

如圖 13 所示，作者提出 DLNA Proxy System(DPS)架構[9]，Home Network 中主要有 DLNA Media Proxy Server(DMPS)與 DMS/DMP 這些設備，當使用者可以利用網路上的一台 PC，向右邊 Home Network 建立 tunnel，或是也可以透過 Home Network 向另一個 Home Network 建立 tunnel。

(29)

21 Internet

Home Network : Private IP

Home Network PC(DMP)

PC(MDS/DMP)

Home Server

PC2 (DMP)

PC1 (DMS) DMS/DMP

DLNA AV Home Network

圖 13. The DLNA Proxy System (DPS) Architecture[9]

如圖 14 所示，在 A 階段中，使用者透過 DMP 可以操作，先建立 network-to-network VPN。在 B 階段中，DMPS 負責管理檔案的分享，DMPS 會收集 DMS 與 DMP 相關設備傳送的訊息，DMS 會在區域網路傳送 Notify，由於 DMPS 內建 Control Point，

因此會送 M-Search，DMS 會回覆 response，當 DMPS 得知 DMS 的存在後，就會傳送 Get Description，DMS 再回覆 response。在 C 階段中，DMPS 會提供一個介面給使用者用，使用者透過這個介面去瀏覽檔案清單，得到檔案的相關資訊，再來透過 port forwarding 的方式，以 media streaming 的方式傳輸到 DMP。在 D 階段中，當 DMS 沒有在使用後或是退出網路時，會傳送 Notify 訊息，終止服務。

(30)

22

DMP Home Server

DMPS

Home Server

DMPS DMS/DMP

Phase A

Phase B

Phase C

Phase D

Conn Req

VPN Conn Req VPN Established VPN Established

Notify Mesg M-Search Search Response

Get Description Request Response

CDS : Browse Content Info HTTP Get

HTTP 200 OK Packet Forwarding

Notify Mesg

圖 14. The Message Call Flows for the DPS[9]

傳統 PPTP VPN 通訊協定中，VPN server 無法轉送 multicast 封包，因此先前有作者提出利用 ATOM 通訊協定[10][11]，代為轉送 VPN client 與 VPN server 之間的封包。

此篇參考文獻與其他參考文獻不同的地方為，考量到產品之間相容性的問題，大多數的作者都是以現有的 UPnP 設備，用標準的 UPnP 通訊協定，搭配另外設計的架構傳輸，但這篇參考有修改標準的設備架構，如圖 15 所示，兩邊的網路必須先建立 tunnel，

UPnP Device Aggregator 主要的功能是收集在區域網路內 UPnP 相關的訊息，UPnP Device Aggregator 是一台 HTTP server，因此 Remote Network 的 Enhanced UPnP Control Point 可以透過 HTTP Get，去取得 UPnP Device Aggregator 收集到的訊息，Control Point 便可得知 home network 中有那些可以用的設備跟服務，另外，遠端的 Enhanced UPnP Device 也可以透過 HTTP POST，告知 UPnP Device Aggregator 有一台 Device 在 remote

(31)

23

network，因此，UPnP Device Aggregator 同時可以擁有 home network 跟 remote network 中設備的資訊。

SSDP SSDP

Remote Network Home Network

Tunnel

UPnP Device Aggregator Enhanced UPnP Control Point

Enhanced UPnP Device

Standard UPnP Device 2

Standard UPnP Device 1 HTTP/

Atom Server

SSDP SSDP Atom feed GET

Atom POST

圖 15. Generic Architecture[10]

如圖 16 所示，Control Point 會送出 Discovery 訊息，Enhanced UPnP Stack 會修改訊息，再傳送給 Home Network 的 UPnP Aggregator，UPnP Aggregator 會把在 Home Network 收集到的可以用的 UPnP 設備回覆給 Enhanced UPnP Stack，Enhanced UPnP Stack 再把結果傳給 Control Point，Control Point 便可直接跟 UPnP Device 溝通。

(32)

24

Remote Device Home Network

UPnP Application (Control Point)

Enhanced UPnP Stack

UPnP Device

Aggregator UPnP Device

UPnP search()

Atom plug

ATOM Get (SSDP:search) ATOM feed

Prepare Atom feed UPnP

search(results) HTTP Get

HTTP 200 OK

HTTP Get HTTP 200 OK

圖 16. Sequence of Actions for Remote Discovery[10]

如圖 17 所示，Remote Device 會送出 advertisement，Enhanced UPnP Stack 修改訊息後再把 notify 傳給 UPnP Device Aggregator，Aggregator 得知 Remote Network 有一個可以使用的 Device，Aggregator 傳送 notify，Control Point 便可直接跟 UPnP Device 溝通。

(33)

25

Remote Device Home Network

UPnP Service Enhanced UPnP Stack

UPnP Device Aggregator

UPnP Control Point

UPnP advertise()

Atom plugin

ATOM Get (SSDP:alive)

Add device

HTTP 200 OK HTTP Get

SSDP:alive

HTTP Get HTTP 200 OK

圖 17. Sequence of Actions for Remote Announcements[10]

(34)

26

第三章系統架構

在以往提到 UPnP 跨網際網路的方法中，大多是在 Home Gateway 上面做修改，

此方法無法動態連線到不同的家庭網路，而且一般非資訊人員的使用者，可能不會修改 Home Gateway 的相關設定，因此，本篇論文提出的方法僅需在個人電腦上操作，

針對區域網路不同的個人電腦，可加入不同的群組環境，如圖 18 所示，Home 1 中的 User 1 與 Home 2 的 User 3 加入 Group 1，此時 User 1 與 User 3 之間傳送的 UPnP 封包，只有同在 Group 1 的 User 可以收到，無法讓 User 2 或 User 4 使用；一樣的道理，

因為同在 Home 3 中的 User 5 與 User 6 加入不同的群組，所以無法收到彼此 UPnP 的封包。在以往的解決方法中，當一家庭網路分享內容於網際網路時，整體家庭網路上之內容會全部被分享，因此以往的解決方法會有隱私與安全上的顧慮，本篇論文提出的方法可以針對使用者做個人化設定，利用群組的概念有效的區隔不在同一個群組但是在同一個家庭網路的成員，同時，同一個家庭網路的成員，可以加入不同的群組，

以上特性可以確保數位內容只能分享給加入同一個群組的使用者，有別於以往其他作者提出將整個區域網路與另一個區域網路連接。

(35)

27

圖 18. 個人化互聯網

本論文提出 Virtual Home Network，Virtual Home Network 這個系統架構會在網際網路中建置一個 Virtual Home Network Manager System 與數個 VLAN server 來提供服務，使用者在網際網路中則扮演 VLAN Client 的角色，Virtual Home Network Manager System 會監控數個 VLAN server 的狀態(開機/關機/可使用/使用中)，如圖 19 所示，

使用流程為(實作畫面會在第四章介紹)：使用者需要在 Virtual Home Network Manager System 建置一個個人帳號，登入 Virtual Home Network Manager System 後便可以管理自己的個人化群組，使用者可以新增個人化群組並自行修改群組成員。

(36)

28

圖 19. 使用流程圖

如圖 20 所示，同一個使用者可以同時新增在不同群組中，而群組清單可以保留在 Virtual Home Network Manager System，提供往後帳號登入後使用，使用本服務時，

透過 Virtual Home Network Manager System，先選取群組，再選擇可使用的 VLAN server，Virtual Home Network Manager System 會與選取的 VLAN server 自動同步，開

(37)

29

放 VLAN server 給個人化群組內的成員使用，群組內的成員就可以透過 VPN tunnel 與 VLAN server 連線，完成 Virtual Home Network 的建置。

圖 20. 個人化群組清單

如圖 21 所示，群組內的成員，登入 Virtual Home Network System 後，查看受邀請的狀態，透過網頁提供的超連結，可以直接連線到 VLAN server，通過身份認證後，

加入 VLAN server。

(38)

30

圖 21. 加入群組

第二章節曾經提出，DLNA 主要產品為 DMP，相當於 UPnP 之 Media Renderer，

與 DMS，相當於 UPnP 之 Media Server，在一般家庭中，使用情境為，使用者分別使用 DMP 或 DMS，如圖 22 所示，跨網際網路資源分享時，DLNA 設備的互動圖，一開始使用者先登入 Manager System 設定群組(step1)，Manager System 會自動將設定同

(39)

31

步至 VLAN server(step2)，再來，使用者必須分別加入 VLAN server 中(step3)，DMP 送出 SSDP Discovery，DMS 回應 200 OK(step4)，DMP 送出 http Get Description，DMS 回應 200 OK(step5)，以上 step4 step5 為 UPnP 通訊協定的標準流程。

圖 22. DLNA 設備互動圖

檔案內容會儲存在 Media Server 的多媒體檔案資料庫中，需要觀看時透過 Control

(40)

32

Point 操作，將檔案從 Media Server 傳送到 Media Renderer 即可播放。在系統架構中，

將 Control Point 與 Media Renderer 實作在同一台個人電腦，而另一台電腦是 Media Server。Control Point 經由 discovery 動作之後得知 Media Server 的存在，接著，Control Point 送出 Get Description 後，Media Server 回應 Description 訊息，內容包括(型號名、

編號、相關 URL)，使用者即可透過 UPnP 的 Control action 去要求 Media Server 提供服務。

先前系統架構中有提出，本實驗設計的是一個個人化群組的互聯網，可以區分在同一個 Home Network 而不在同一個群組的使用者，如圖 23(a)所示，不限制群組以外的使用者時，User1 可以同時看到同一個 Home Network 的 User2 與不在同一個 Home Network 但在同一個群組的 User3，為達到個人化群組的目的，可以限制其資訊廣播範圍，如圖 23(b)所示，在限制群組後，User1 僅能看到同一個群組中的 User3。

(41)

33

(a). 無區分群組

(b). 區分群組圖 23. 區分群組示意圖

(42)

34

圖 23(b)區分群組以達到本論文之個人化互聯網之目的係以下列方式完成：檔案資源分享者，如 User2，可在其使用者介面，如圖 24 所示，關閉其分享功能。

圖 24. 網路介面

(43)

35

第四章實作與結果

4.1 系統實作

在系統架構中有提出 Virtual Home Network 使用流程圖，從以下實作畫面可以看到，使用 Virtual Home Network 的使用者可以分為兩種，一種是設定群組的主動邀請者，另一種是被邀請者，主動邀請者需要建立群組並且加入 member，被邀請者只需要加入群組，以下展示兩種使用者的相關流程。

如圖 25 所示，使用本服務的第一個步驟，透過瀏覽器，開啟網頁，至 Virtual Home Network System。

圖 25. 建立群組之 Start 步驟

(44)

36

如圖 26 所示，每一個使用者需要擁有一個個人帳號，已經擁有帳號的用戶，可以直接登入系統，沒有帳號的用戶，請先新增帳號。

圖 26. 建立群組之 Create account 步驟

如圖 27 所示，本系統最重要的功能就是可以設定個人化的群組，沒有設定過群組的用戶，可以新增群組(Create New Group)，而過去曾經登入過系統並且新增過群組的用戶，群組會被保留在本系統中，以後可以重複使用。

(45)

37

圖 27. 建立群組之 Add new group 步驟

如圖 28 所示，想要新增群組時，輸入群組名單，並按下 Add 便可以完成新增動作。

(46)

38

圖 28. 建立群組之 Create group 步驟

如圖 29 所示，選取群組後，可以看到使用者清單，用戶本身就是使用者清單的第一個成員。

(47)

39

圖 29. 建立群組之 Select group 步驟

如圖 30 所示，使用者可以自由設定群組內的成員。

圖 30. 建立群組之 Add members 步驟

(48)

40

如圖 31 所示，當使用者欲使用本服務時，設定群組成員後，可以選擇需要的 VLAN server，選擇完成後，便完成 Virtual Home Network 的環境設定。

圖 31. 建立群組之 Select VLAN server 步驟

如圖 32 所示，在前面介紹建立 Virtual Home Network 的步驟後，群組內的成員，

可以登入 Virtual Home Network System，查看受邀請的狀態，透過網頁提供的超連結，

可以直接連線到 VLAN server。

(49)

41

圖 32. 加入群組之 Check invited status 步驟

如圖 33 所示，VLAN server 會提供建立 tunnel 必備的 configuration file，用戶必須下載此檔案。

(50)

42

圖 33. 加入群組之 VLAN server url 步驟

如圖 34 所示，執行前面 VLAN server 下載回來的檔案，利用用戶登錄密碼做驗證，完成登入動作，就完成 Virtual Home Network 全部步驟，用戶即可使用 UPnP 軟體做跨網際網路的資源分享。

(51)

43

圖 34. 加入群組之 Join VLAN server 步驟

本篇論文實驗使用 PC(OS:Ubuntu 10.04) 架設 VLAN server ，使用者使用 PC(OS:Windows XP)架設 DMS、DMP，使用者從 Virtual Home Manager System 尋找 VLAN server 時間需耗時約 0.42 秒，當 VLAN server 設定完成後，使用者連線至 VLAN server 耗時約 9 秒，如表 2 所示，UPnP 在區域網路底下與 UPnP 跨 VLAN server 的比較說明。

表 2. UPnP 網路環境比較

網路環境特性

區域網路無需建立 tunnel 連線，但僅能在同一個區域網路使用跨 VLAN server 需要建立 tunnel 連線，可以跨網際網路傳送

(52)

44

如圖 35 所示，在 UPnP Discovery 與 Get Description 流程中，當 DMS 的 ARP cache 不存在或是已經過期時，在 DMS 回應 SSDP response 之前，會先做 ARP 的查詢，產生 ARP request 與 ARP response 步驟。

SSDP request

Get Description ARP request

ARP response SSDP response

Description response

t1 t2

t3 t4

t5

DMP DMS

圖 35. DMS without ARP table (IP, MAC address)

如圖 36 所示，當 DMS 存在未過期的 ARP cache 時，UPnP 步驟流程。此時，DMS 回應 SSDP response 時，就不會先做 ARP 查詢。

(53)

45

SSDP request

Get Description SSDP response

Description response t6

t7

DMP DMS

圖 36. DMS with ARP table (IP, MAC address)

如表 3 所示，UPnP 在不同網路環境中，with/without ARP table 的比較。

表 3. UPnP 耗時(單位:秒) 網路

環境

t1 t2 t3 t4 t5 t6 t7

區域網路

0.827559 0.000015 0.000075 0.827649 0.001682 0.713077 0.001655

跨 VLAN server

0.859299 0.000025 0.000228 0.859552 0.004026 0.792402 0.003353

(54)

46

4.2 情境展示

根據本論文提出的情境，展示其系統，如圖 37 所示，包含完整的拓撲架構。

Internet VLAN server

VLAN client / DMP VLAN client / DMS

ADSL modem

Manager system

chu 圖 37. 拓撲架構

如圖 38 所示，使用者使用 DMS 時，DMS 分享的資料夾。

(55)

47

圖 38. DMS 分享的資料夾

如圖 39 所示，DMS 分享的資料夾對應檔案總管的位置，內含欲分享的檔案。

(56)

48

圖 39. 檔案總管

如圖 40 所示，DMS 之主機資訊。

(57)

49

圖 40. ipconfig in DMS

如圖 41 所示，使用者(DMP 端)透過 ADSL 連線到網際網路。

(58)

50

圖 41. ipconfig in DMP

如圖 42 所示，DMP 可用的 DMS 設備以及其可使用的檔案清單。

(59)

51

圖 42. 播放清單

如圖 43 所示，使用者選取欲播放的檔案後，DMP 播放檔案的畫面。

圖 43. 播放檔案中

(60)

52

第五章結論

本論文提出使用 VPN 的方式來轉送 multicast 封包，藉此可以將多個數位家庭網路之 UPnP 設備互連一起。此一方法優於以前所提出之方法在於，本實驗設計的個人化群組互聯網，在資源分享中利用區分群組的方式，達到分享的檔案內容僅能給同一個群組的使用者存取。經實驗後證明 UPnP 檔案資源分享可以跨網際網路執行，且 UPnP 流程的封包傳遞速度皆在時間容忍範圍之內，跨網際網路資源分享功能將會是數位家庭的趨勢，透過 UPnP 可以快速的佈署網路環境，讓使用者可以簡單且容易的操作所有的設備。

由於使用者可以同時分享資源於個人家庭網路與個人化互聯網，所以使用者於任一方取得之檔案資源，亦可於另一方分享，此一問題值得後續考量。此外，隨著網際網路發展，未來將有越來越多的使用者分享多媒體檔案，現有的軟體並不支援針對不同群組提供獨立的資料夾目錄，當資料夾被分享後，使用者皆可以存取，未來軟體開發上，應該要列入程式開發上的議題，設計出讓不同群組可以存取各自的資料夾。

在未來可以考慮利用 P2P 的方式建置 VLAN 環境，每個節點都可以作為 client 與 server，使節點之間互有連結，如此一來，不需要建置 VLAN server 便可達成環境建置，如何有效的分享資源值得去探討與研究。

(61)

53

參考文獻

[1] Wei-Shun Liao, Yen-Ju Huang, and Chih-Lin Hu, "Mobile Media Content Sharing in UPnP-Based Home Network Environment," in Proceedings of International Symposium on Applications and the Internet Workshops, Hiroshima, Japan, Jan. 2007, pp. 52–55.

[2] UPnP Forum, UPnP Device Architecture 1.1, Oct. 2008, Available : www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf

[3] Taein Hwang, Hojin Park, and Jinwook Chung, "Personal Mobile A/V Control Point for Home-to-Home Media Streaming," IEEE Transaction on Consumer Electronics, Vol. 54, No. 1, pp. 87-92, Jan 2008.

[4] Taein Hwang, Hojin Park, and Jin Wook Chung, "Home-to-Home Media Streaming System Based on Adaptive FastReplica," in Proceedings of 2009 11th International Conference on Advanced Communication Technology, Gangwon-Do, South Korea, Feb 2009, pp. 1665-1666.

[5] Chuan-Feng Chiu, Steen J. Hsu, and Sen-Ren Jan, "The Design of UPnP-based Home Environment over Peer-to-Peer Overlay Network," in Proceedings of The 2008 International Workshop on Mobile Systems, E-commerce and Agent Technology(MSEAT’2008) In conjunction with The First IEEE International Conference on Ubi-media Computing, Lanzhou, China, July 2008 - Aug 2008, pp.

508-512.

[6] Hyun Yong Lee and Jong Won Kim, "An Approach for Content Sharing among UPnP Devices in Different Home Networks," IEEE Transactions on Consumer Electronics, Vol. 53, No. 4, pp. 1419-1426, Nov 2007.

[7] Narayanan Venkitaraman, "Wide-Area Media Sharing with UPnP/DLNA," in

(62)

54

Proceedings of the 5th IEEE Consumer Communications and Networking Conference(CCNC’08), Las Vegas, NV, USA, Jan 2008, pp. 294-298.

[8] Tobias Wegner, "A Modular UPnP Proxy for Secure Remote Access," in Proceedings of IEEE Computer Society, Los Alamitos, CA, USA, Feb 2010, pp. 72-77.

[9] Jung-Tae Kim, Yeon-Joo Oh, Hoon-Ki Lee, Eui-Hyun Paik, and Kwang-Roh Park,

"Implementation of The DLNA Proxy System for Sharing Home Media Contents,"

IEEE Transactions on Consumer Electronics, Vol. 53, No. 1, pp. 139-144, Feb 2007.

[10] Petros Belimpasakis and Vlad Stirbu, "Remote Access to Universal Plug and Play (UPnP) Devices Utilizing the Atom Publishing Protocol," in Proceedings of the 3rd International Conference on Networking and Services (ICNS 2007), Athens, Greece, Jun 2007, pp. 59-64.

[11] Petros Belimpasakis, Seamus Moloney, Vlad Stirbu, and Jose Costa-Requena, "Home Media Atomizer: Remote Sharing of Home Content-without Semi-trusted Proxies,"

IEEE Transactions on Consumer Electronics, Vol. 54, No. 3, pp. 1114-1122, Aug 2008.

[12] UPnP Forum, UPnP AV Architecture 1, Sep. 2008, Available : www.upnp.org/specs/av/UPnP-av-AVArchitecture-v1.pdf

[13] DLNA, DLNA 1.5, Mar. 2006, Available : www.dlna.org [14] OpenVPN, Available : openvpn.net

[15] UPnP Forum, Internet Gateway Device, Dec. 2010, Available : upnp.org/specs/gw/igd2/

(63)

55

[16] Jesus Saez G6mez-Escalonilla, Julio Angel Cano Romero, Natividad Martinez Madrid, and Ralf Seepold, "A Gateway-based Solution for Remote Accessing to Residential UPnP Services Networks," in Proceedings of 2010 8th Workshop on Intelligent Solutions in Embedded Systems(WISES), Crete, Greece, Jul 2010, pp.

29-34.

中 華 大 學

中 華 大 學 碩 士 論 文

通用型隨插即用跨網際網路 資源分享技術之研究