標籤：dlna upnp 媒體伺服器
隨著移動互連網潮流，多裝置互動逐漸走入人們生活。比如，手機QQ和PC之間的檔案分享權限設定，手機可以觀看PC上的視頻，智能路由器等。而相關的嘗試在很久以前就開始了，比如Upnp和dlna。dlna是一堆業界大哥，將很多其它協議組合起來，在此基礎定義了一些裝置，互動，使得裝置之間的媒體互聯變得可能。而其中Upnp是核心協議，在底層基於PTC/IP，涉及DHCP等，都是被廣泛使用的協議。而在上層還需要抽象出一些dlna裝置，對媒體流的描述，這就是dlna了。
Upnp是intel首先發起，並提供開源實現（libupnp），後來又發生一些變化，目前還是能下載到該開源開發包。而網上有相關的開發文檔：UPnP編程指南.pdf，UPNP[1].0-Chinese_UPNP中文版。而對於Upnp本身，比較重要的協議有UPnP-arch-DeviceArchitecture-v1.0-20081015，基本上奠定了Upnp基礎，在此之上還定義了一些應用，比如媒體服務，其中定義了整個媒體服務的架構，其中包含媒體伺服器，內容服務，串連管理，媒體傳輸，渲染控制，進而實現媒體的資源共用，互動。
而在Upnp的基本架構中，分為定址,發現,描述,控制,事件,展示6個方面，解決了如何在網路中自動探索裝置，知道裝置的屬性，控制裝置進行某些操作，接收裝置上的事件通知等問題。
由於是PC端使用的sdk，主要考慮PC作為媒體伺服器，將PC上的媒體共用到其它裝置上的功能。（其實編譯為移動端的so也行）
libupnp提供什麼樣的api來方便構建Upnp應用呢，這裡基於ushare來簡單說明（可以看作是ushare的簡單介紹）。
首先sdk內部會有機制負責Upnp裝置的尋找，發現，控制。而暴露給使用者的介面就是註冊裝置及其回調，裝置操作api，註冊控制點回調等。其次，sdk實現一個WebServer，使得使用者可以實現一個Web伺服器。因為Upnp很多資料互動是基於http的。
然而，該sdk有些不足：只能註冊一個裝置，只能在一個網路工作。不過考慮使用sdk的情境，一個裝置足以，通過在上面添加更多的Service使得裝置可擴充。而在一個網路工作也能滿足絕大多數情境的使用：在一個家用網路中，PC有多個IP，且每個網路都有媒體需求的情境是少見的。
目前為止，使用該sdk來實現媒體伺服器，需要如下流程：
初始化Upnp->啟動WebWerver並註冊回調->註冊裝置和回調->註冊控制點回調。
我們假定把D盤下一個叫作server_root的檔案夾共用出去，那麼需要做什麼呢？
首先需要裝置描述，服務描述，這是MediaService中所定義的。
然後要的是共用檔案的元資訊，構造一個內部的資料結構，使得其中有檔案夾下面所有檔案的資訊。元資訊的擷取可以在服務啟動時同步擷取。
接著是實現裝置回調。最重要的莫過於控制動作回調，其它的比如定閱，擷取變數等暫時不用考慮。實現完控制動作回調基本上服務就可用了。而控制動作回調中最重要的就是實現瀏覽的功能。這樣用戶端就可以知道根目錄下的item列表，列表下面的item的屬性。這樣的動作是在UPnP-av-ContentDirectory-v1-Service-20020625中所描述的：媒體伺服器下面的內容目錄服務，伺服器描述了瀏覽動作應該帶的參數，做出的回應。要做出對應的回應邏輯，只需要知道上述檔案元資訊。
最後是實現檔案內容傳輸。上面在產生瀏覽動作的返回資料時，裡面的item中包含了檔案內容的url，向該url發請求時會由sdk的WebServer處理，然後產生回調。回調就是個檔案IO，包含擷取檔案資訊，開啟檔案，讀檔案，寫檔案，Seek，關閉檔案。使用者需要根據回調時傳入的url找到對應的檔案元資訊，然後做出對應動作即可。比如在開啟檔案的時候，建立一個檔案資訊，檔案資訊中包含檔案控制代碼，讀位置等，然後這個檔案資訊作為cookie給WebServer。在讀檔案的時候這個Cookie還帶著，於是就可以讀一段資料傳回去。
至此，實現媒體伺服器已經很清楚了，但是，只能共用一個檔案目錄。更多功能的擴充需要修改檔案元資訊的定義，比如引入虛擬目錄。可以讓在瀏覽動作中不可見，但是使用者訪問url會返回資料嗎？可以，實現非常簡單。
然而，構建檔案元資訊比較耗時，怎麼解決呢？
可以建個資訊緩衝。可以分段負載檔案元資訊。
如何保證目錄裡和磁碟上的檔案同步呢？
可以通過一些系統機制實現。不過一般沒必要。
而媒體伺服器的效果可以參考小度wifi（影音共用，隔空傳物），百度影音開啟區域網路dlna共用後可以在lan內觀看百度影音上的影片（不僅是PC上的，互連網上的影片也可以）。
