上節說過了網絡卡的選型，之所以網絡卡的選型如此重要，主要是因為Miracast網絡卡相比較於普通的網絡卡多了個P2P功能，底層可靠了，才能很好的進行接下來的上層開發，如果我們已經有了可靠的P2P網絡卡以及網絡卡驅動，那我們接下來就可以先進行P2P部分上層程式碼的開發啦。

1.P2P的模型

圖1 p2p的基本模型

P2P Group Owner: 類似AP功能，控制Wi-Fi P2P組，能讓支援P2P的裝置連線上。
P2P Client：連線GO的裝置。

2一對一時候的流程

• scan階段：兩個裝置均對外發送Probe Req請求幀，蒐集周圍所有裝置或網路資訊，但是裝置不會響應Probe Req請求幀。
• find階段:主要把包括listen和search兩種，listen的時候p2p裝置選擇一個隨機的間隔(預設值分別是1和3次100TU)。p2p裝置再用這個隨機的間隔在social頻段上監聽。接收匹配引數的Probe Req，併發送一個Probe res。
• search態的時候：搜尋social頻段，在social頻段傳送probe req資訊，此資訊包含要search的Requested裝置型別，裝置ID。
• group formation階段按：GO協商：p2p裝置初始化group formation或者響應來自另一個p2p裝置的go協商req，GO向GC傳送beacon幀，authentication，association，以及WSC和4次握手。

圖2 p2p一對一流程

兩個P2P裝置互相discover，最終頻率鎖定在ch6上，在device1的listen段進行group形成。

圖2所示為兩個P2P Device的Discovery流程，其中：

• Discovery啟動後，Device首先進入Scan Phase。在這一階段，P2P裝置在其支援的所有頻段上都會發送Probe Request幀。
• Scan Phase完成後，Device進入Find Phase。在這一階段中，Device將在Listen和Search State中切換。根據前面的介紹，每一個裝置的Listen Channel在Discovery開始前就已確定。中
  Device 1的Listen Channel是1，而Device 2的Listen Channel是6。
• 在Find Phase中，P2P規範對Device處於Listen State的時間也有所規定，其時間是100TU的整數倍，倍數值是一個隨機數，位於minDiscoverableInterval和maxDiscoverableInterval之間。這兩個值預設為1和3，而廠商可以修改。選擇隨機倍數的原因是為了防止兩個Device進入所謂的Lock-Step怪圈，即兩個Device同時進入Listen State，等待相同的時間後又同時進入Search State。如此，雙方都無法處理對方的Probe Request資訊（Search State中，Device只發送Probe Request）。圖中，Device 1第一次在Listen State中待了2個100TU，而第二次在Listen State中待了1個100TU。
• 當Device處於Find Phase中的Search State時，它將在1,6,11頻段上傳送Probe Request幀。注意，只有當兩個裝置處於同一頻段時，一方傳送的幀才能被對方接收到。
• GO協商
• 發現對方後，下一步就點選進行連線，而連線的第一步就是確認各自的角色，誰做GO，誰做GC，WiFi direct通過增加ACTION幀的互動來達到此目的。

圖3 WFD的GO協商過程

GO協商共包含三個型別的Action幀：GO Req、GO Resp、GO Confirm。GO Req和GO Resp包含GO Intent的IE，是一個0到15的整數值，通過這兩個值的大小來確定GO，具體方法如下圖。如果Intent不相等時，誰大誰做GO；如果相等時且小於15時，根據GO Req的隨機數Tie Breaker來決定，Tie Break為1就自己做GO，否則對方做GO；如果相等且等於15，GO協商失敗，這種情況說明A和B都必須成為GO，誰也不能妥協，那麼只能以失敗告終。

圖4 GO的選擇流程

事實上，一般情況下GO協商會有5個幀互動，P2P流程圖已經清晰的展現出來了，一開始會讓人比較迷惑，下面舉例說明。假設有兩個P2P裝置A（Listen通道為1）和B（Listen通道為11），在A的P2P介面點選B進行連線，這時A首先會在11通道傳送GO Req，傳送需要持續一段時間，因為B可能會處於Search狀態，所以持續的時間至少要大於B的Search時間；直到B切換為Listen狀態，才能收到 GO Req，收到後立即在11通道回覆GO Resp並給上層應用傳送對應訊息，應用提示使用者是否同意A的連線。注意B剛剛回復的GO Resp包含的狀態是fail:information is unavailable，A收到這個訊息後不做任何動作，繼續等待。直到使用者點選B的同意後，B會再發起GO Req，由於A是連線發起方，他不用再去提醒使用者同意，直接響應成功的GO Resp。最後B通過GO Confirm確認GO協商結束。

3.WPS流程
Wi-Fi Direct採用WPS PBC方式來協商金鑰，我們知道當手機和AP進行WPS連線時，需要先按一下AP上的WPS按鈕，再點選手機上的WPS按鍵，兩者會自動建立連線。其實按AP的WPS按鈕的作用是讓他在後續兩分鐘的Beacon幀WPS IE裡置上一個PBC標誌，手機端WPS按鍵用於啟動WPS連線流程，如果掃描到的Beacon幀有PBC標誌就開始連線和WPS金鑰協商。
Wi-Fi Direct省去了WPS按鍵流程，協商為GO的P2P裝置轉換為GO狀態時自動在Beacon幀裡增加PBC標誌，GC也自動啟動WPS連線流程。這裡隱藏著一個問題，如果當前環境有AP剛好處於PBC狀態或者當前有多組P2P裝置在連線，那麼很有可能GC掃描到的AP列表裡有一個以上的AP包含PBC標誌，引起PBC Overlap異常，導致P2P連線失敗。這個問題概率很小，但使用WPS方式的裝置都會存在，需要引起重視，當然P2P可以根據之前GO協商的MAC地址進行區分來避免。

4.4次握手
WPS流程只是協商出一個公共的Key，這個Key還不能用於資料加密。4次握手的作用是以公共Key為引數協商出PTK和GTK，之後進行加密資料傳輸。
P2P流程圖連線流程執行了兩個auth和associa，在WPS結束後GC發起的deauth沒有在流程圖表現出來。為什麼不繼續4次握手來減少互動次數呢，這樣做的目的是最大程度的相容原有的Wi-Fi連線流程，投入較少的改動來實現P2P功能。

對DLNA/Airplay/Miracast/Widi感興趣的同學可進QQ群 582349005交流。