Step0：地址分配，也就是裝置通過DHCP等協議獲取IP地址的過程。UPnP通訊的前提條件。

Step1：裝置發現（Discovery），controlpoint通過這一步驟找到感興趣的UPnP裝置。

Step2：裝置描述（Description），control point獲取裝置描述資訊，從而瞭解裝置所能提供的服務型別等具體資訊。

Step3：裝置控制（Control）。

Step4：Eventing。

Step5：Presentation。

本系列例項中所使用的環境：

DMS：VMware + Ubuntu14 + MiniDLNA1.13。IP地址是192.168.159.129。

DMP： Win7 + Foobar + foo_upnp外掛（0.99.48）。 IP地址是192.168.159.1。

裝置發現是UPnP的第一個步驟。對應協議棧如圖所示：

SSDP的Notification一共有三種類型——ssdp:alive，ssdp:byebye和ssdp:update。當一個新裝置加入到網路中後，按照協議應向網路中的控制點廣播ssdp:alive通告，即advertisement。

在我們的環境中，在關閉Foobar的情況下首先啟動miniDLNA。這時DMS立即連續傳送了24條SSDP報文，即廣播的advertisement。目的IP為協議中定好的廣播地址239.255.255.250，斷口號則固定為1900（[1]文件1.2節），如下圖所示：

這24條報文可以分為4組，每組6條。第1-6條報文與第7-12條報文的內容完全一致。第13-18條報文與19-24條報文的內容一致。其中第三組報文構成一套完整的ssdp:alive通告，向網路中的其它裝置宣告自己存在。第一組報文是與第三組報文內容相對應的ssdp:byebye通告。這是為了確保在釋出alive通告之前，清除control point上可能存有的關於本裝置及服務的舊的狀態資訊。第二組與第四組報文分別是第一組與第四組報文的重複，這是因為SSDP是基於非可靠的UDP傳輸，UPnP協議允許裝置在釋出通告的時候重複一兩遍，以確保感興趣的control point能發現自己。

我們主要分析一下第三組報文。

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:uuid:4d696e69-444c-164e-9d41-000c29955b1d
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:upnp:rootdevice
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::upnp:rootdevice
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:device:MediaServer:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:device:MediaServer:1
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:service:ContentDirectory:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:service:ContentDirectory:1
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:service:ConnectionManager:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:service:ConnectionManager:1
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:1
NTS:ssdp:alive
 

前三條報文一起構成了device的通告，其中CACHE-CONTROL欄位描述了這條alive通告的生存時間。網路中的裝置在傳送首條alive通告之後，會每隔一段時間重複傳送一套alive通告，或者叫做心跳報文。此條報文中max-age等於1800，即UPnP協議推薦的預設值（1800秒即30分鐘），如果control point超過半個小時仍然沒有收到下一條心跳報文，則會認為這個裝置已經掛掉，並將該裝置從可用裝置列表中移除。

LOCATION欄位包含了一個絕對路徑的URL。在UPnP通訊的第二個步驟裝置描述中，control point將通過這個URL獲得裝置的描述資訊。

三條報文的NT/USN欄位各不相同。UPnP協議規定對於rootdevice來說，每次通告共需要傳送三條報文。對應的NT欄位分別是rootdevice，UUID和裝置型別。如果裝置還包含有embedded device的話，每個embedded device則只需要繼續傳送後兩種NT欄位構成的報文。這一部分的協議具體見文件[1]的29頁。

後三條報文則分別通告了該裝置所支援的服務（service）。分別是ContentDirectory，ConnectionManager和微軟自己的X_MS_MediaReceiverRegistrar。

ContentDirectory的詳細描述見文件[3]。主要是定義了mediaserver提供的檔案瀏覽服務。miniDLNA支援這一服務後，control point就可以通過ContentDirectory:Browse動作來進行檔案目錄瀏覽。

ConnectionManager的詳細描述見文件[2]。定義了裝置間的流媒體傳輸模型。這兩個實際上是DLNA MediaServer必不可少的service。

X_MS_MediaReceiverRegistrar是微軟自己定義的服務，miniDLNA較新的版本支援這一服務主要是為了提供對Xbox的支援。

miniDLNA啟動之後，再啟動安裝了foo_upnp外掛的foobar。這相當於在windows主機中啟動了一個MediaRenderer和一個MediaServer（通過Notify報文內容分析，兩者實際上是作為兩個獨立的rootdevice），提供自己對應的服務。這部分SSDP報文的內容與上面分析的類似，也是在傳送一套完整的ssdp:alive報文之前先發送一套完整的ssdp:byebye報文，MediaRenderer和MediaServer兩個裝置分別獨立通告自己的裝置型別，uuid以及提供的service等等。不做具體分析了。

做為control point的MediaRenderer，在廣播完自己的通告報文之後，向相同的廣播地址傳送了一條search請求。這部分報文格式的詳細描述見文件[1]的1.3。報文內容如下：

M-SEARCH * HTTP/1.1
MX: 5
ST: upnp:rootdevice
MAN: "ssdp:discover"
User-Agent: UPnP/1.0 DLNADOC/1.50 Platinum/1.0.4.2-bb / foobar2000
Connection: close
Host: 239.255.255.250:1900

其中第一行M-SEARCH * HTTP/1.1表明這是一條search request資訊。

MX：5是請求的最大等待時間，單位是秒。UPnP協議規定網路中響應請求的裝置應該隨機在0~最大等待時間範圍內作出響應。這是為了避免網路規模較大時，大家同時給響應造成網路擁塞。同理control point也可以跟據網路的規模大小設定適當的最大等待時間。

MAN欄位是為了遵守HTTP  Ex tension  Framework的協議規範，在這裡是一個固定值。

最重要的欄位是ST欄位，即search target。在本例中target是rootdevice，那麼隨後miniDLNA作為rootdevice將給出迴應。

前文說作為rootdevice，miniDLNA一共需要三條報文來通告自己的device。那麼為響應control point的searchrequest，它只需要把對應於search target的一條通告報文重新發送一遍即可。如下：

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Sat, 25 Oct 2014 04:13:26 GMT
ST: upnp:rootdevice
USN: uuid:4d696e69-444c-164e-9d41-000c29955b1d::upnp:rootdevice
EXT:
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
LOCATION: http://192.168.159.129:8200/rootDesc.xml
Content-Length: 0

簡單總結一下，裝置發現過程其實很好理解：

DMS啟動：

                     大家好，我來了，我是rootdevice，我的uuid是xxx，我是MediaServer哦

                     我還能支援A服務，B服務和C服務哦~

                     （此後每隔一段時間傳送一遍，表明我還活著）

DMR啟動：

                     大家好，我來了，我是rootdevice，我的uuid是xxx，我是MediaRenderer哦

                     我還能支援D服務E服務和F服務哦~

                     （此後也要每隔一段時間重複傳送一遍，生怕別人以為它掛了）

DMR：        對了，我是controlpoint，是rootdevice的吱一聲唄~

DMS：

                     吱~~

（OK，裝置發現完成！）

[1], UPnP-arch-DeviceArchitecture-v2.0-20140901.pdf   

[2], UPnP-av-MediaServer-v1-Device-20020625.pdf  

[3], UPnP-av-ContentDirectory-v1-Service-20020625.pdf

[4], UPnP-av-ConnectionManager-v1-Service-20020625.pdf