基於DLNA實現iOS,Android投屏:SSDP發現裝置

BrikerMan發表於2016-04-26

基於DLNA實現iOS,Android投屏:SSDP發現裝置

SSDP能夠在區域網能簡單地發現裝置提供的服務。SSDP有兩種發現方式:主動通知和搜尋響應方式。

定址

UPnP 技術是架構在 IP 網路之上。因此擁有一個網路中唯一的 IP 地址是 UPnP 裝置正常工作的基礎。UPnP 裝置首先檢視網路中是否有 DHCP 伺服器,如果有,那麼使用 DHCP 分配的 IP 即可;如果沒有,則需要使用LLA技術來為自己找適合的IP地址。

另外,在 UPnP 執行過程中,UPnP 裝置都需要週期性檢測網路中是否有 DHCP 伺服器存在,一旦發現有 DHCP 伺服器,就必須終止使用 LLA 技術獲取的 IP 地址,改用 DHCP 分配的 IP 地址。

發現

SSDP

SSDP:Simple Sever Discovery Protocol,簡單服務發現協議,此協議為網路客戶提供一種無需任何配置、管理和維護網路裝置服務的機制。此協議採用基於通知和發現路由的多播發現方式實現。協議客戶端在保留的多播地址:239.255.255.250:1900(IPV4)發現服務,(IPv6 是:FF0x::C)同時每個裝置服務也在此地址上上監聽服務發現請求。如果服務監聽到的發現請求與此服務相匹配,此服務會使用單播方式響應。

常見的協議請求訊息有兩種型別,第一種是服務通知,裝置和服務使用此類通知訊息宣告自己存在;第二種是查詢請求,協議客戶端用此請求查詢某種型別的裝置和服務。
iOS中使用GCDAsyncUdpSocket傳送和接受SSDP請求、響應及通知,安卓也需要用類此框架來完成

所以我們發現裝置也有兩種方法

  1. 主動通知方式:當裝置加入到網路中,向網路上所有控制點通知它所提供的服務,通知訊息採用多播方式。
  2. 搜尋——響應方式:當一個控制點加入到網路中,在網路搜尋它感興趣的所有裝置和服務,搜尋訊息採用多播方式傳送,而裝置針對搜尋的響應則是使用單播方式傳送。

SSDP 裝置型別及服務型別

裝置型別 表示文字
UPnP_RootDevice upnp:rootdevice
UPnP_InternetGatewayDevice1 urn:schemas-upnp-org:device:InternetGatewayDevice:1
UPnP_WANConnectionDevice1 urn:schemas-upnp-org:device:WANConnectionDevice:1
UPnP_WANDevice1 urn:schemas-upnp-org:device:WANConnectionDevice:1
UPnP_WANCommonInterfaceConfig1 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
UPnP_WANIPConnection1 urn:schemas-upnp-org:device:WANConnectionDevice:1
UPnP_Layer3Forwarding1 urn:schemas-upnp-org:service:WANIPConnection:1
UPnP_WANConnectionDevice1 urn:schemas-upnp-org:service:Layer3Forwarding:1
服務型別 表示文字
UPnP_MediaServer1 urn:schemas-upnp-org:device:MediaServer:1
UPnP_MediaRenderer1 urn:schemas-upnp-org:device:MediaRenderer:1
UPnP_ContentDirectory1 urn:schemas-upnp-org:service:ContentDirectory:1
UPnP_RenderingControl1 urn:schemas-upnp-org:service:RenderingControl:1
UPnP_ConnectionManager1 urn:schemas-upnp-org:service:ConnectionManager:1
UPnP_AVTransport1 urn:schemas-upnp-org:service:AVTransport:1

主動通知方式

當裝置新增到網路後,定期向(239.255.255.250:1900)傳送SSDP通知訊息宣告自己的裝置和服務。

宣告訊息分為 ssdp:alive(裝置可用)ssdp:byebye(裝置不可用)

ssdp:alive 訊息

ssdp:byebye 訊息

當裝置即將從網路中退出時,裝置需要對每一個未超期的 ssdp:alive 訊息多播形式傳送 ssdp:byebye 訊息,其格式如下:

搜尋——響應方式

當控制點,如手機客戶端,加入到網路中,可以通過多播搜尋訊息來尋找網路上感興趣的裝置。我寫DLNA模組時候也用主動搜尋方式來發現裝置。主動搜尋可以使用多播方式在整個網路上搜尋裝置和服務,也可以使用單播方式搜尋特定主機上的裝置和服務。

多播搜尋訊息

一般情況我們使用多播搜尋訊息來搜尋所有裝置即可。多播搜尋訊息如下:

如果需要實現投屏,則裝置型別 STurn:schemas-upnp-org:service:AVTransport:1

多播搜尋響應

多播搜尋 M-SEARCH 響應與通知訊息很類此,只是將NT欄位作為ST欄位。響應必須以一下格式傳送:

其中主要關注帶有 * 的部分即可。這裡還有一個大坑,有些裝置返回來的欄位名稱可能包含有小寫,如LOCATION和Location,需要做處理。
此外還需根據LOCATION儲存裝置的IP和埠地址。
響應例子如下:

描述

控制點發現裝置之後仍然對裝置知之甚少,僅能知道UPnP型別,UUID和裝置描述URL。為了進一步瞭解裝置和服務,需要獲取並解析XML描述檔案。
描述檔案有兩種型別:裝置描述文件(DDD)服務描述文件(SDD)

裝置描述文件

裝置描述文件是對裝置的基本資訊描述,包括廠商製造商資訊、裝置資訊、裝置所包含服務基本資訊等。

裝置描述採用XML格式,可以通過HTTP GET請求獲取。其連結為裝置發現訊息中的Location。如上述裝置的描述檔案獲取請求為

裝置響應如下

其中響應訊息體為XML格式的裝置描述內容。資訊結構比較明確,就不一一介紹了。解析該XML,儲存裝置的一些基本資訊如 deviceTypefriendlyNameiconList 等。之後我們關注該裝置提供的服務列表,投屏最關注的服務為 urn:schemas-upnp-org:service:AVTransport:1:

如只需要實現簡單的投屏,則儲存urn:schemas-upnp-org:service:AVTransport:1服務的上述資訊即可。如需要進一步瞭解該服務,則需要獲取並解析服務描述文件。

坑點1:有些裝置 SCPDURLcontrolURLeventSubURL 開頭包含 / ,有些裝置不包含,拼接URL時需要注意。

服務描述文件

為了實現簡單的投屏和控制(播放、暫停、停止、快進)操作並不需要解析服務描述檔案。所有動作均為UPnP規範動作,具體動作請求參見基於DLNA實現iOS,Android投屏:SOAP控制裝置

服務描述文件是對服務功能的基本說明,包括服務上的動作及引數,還有狀態變數和其資料型別、取值範圍等。

和裝置描述文件一致,服務描述文件也是採用XML語法,並遵守標準UPnP服務schema檔案格式要求。獲取上述服務SDD語法如下:

裝置響應如下:

  • actionList 目前服務上所包含的動作列表。
  • actionList 目前服務上所包含的狀態變數。

以Pause動作為例

為了實現簡單的投屏和控制(播放、暫停、停止、快進)操作並不需要解析服務描述檔案。所有動作均為UPnP規範動作,具體動作請求參見基於DLNA實現iOS,Android投屏:SOAP控制裝置

相關文章