标签：android   style   blog   http   color   使用   os   io   

本章主要内容：

• 介绍Wi-Fi P2P相关知识；
• 介绍Android中WifiP2pService、wpa_supplicant的相关代码。

7.1  概述

承接第6章介绍的WSC，本章将继续介绍Wi-Fi Alliance（Wi-Fi联盟）推出的另外一项重要技术规范Wi-Fi P2P。该规范的商品名为Wi-Fi Direct，它支持多个Wi-Fi设备在没有AP的情况下相互连接。

在Android平台的Wi-Fi相关模块中，P2P的功能点主要集中在：

• Android Framework中的WifiP2pService，其功能和WifiService类似，用于处理和P2P相关的工作。
• wpa_supplicant中的P2P模块。

和WSC一样，本章的分析拟采用如下方法：

• 首先将介绍P2P所涉及的基础知识。
• 然后再分析和P2P相关的模块，包括Settings、WifiP2pService以及WPAS。

下面，先来认识一下P2P。

7.2  P2P基础知识介绍

WFA定义的P2P协议文档全名为“Wi-Fi Peer-to-Peer（P2P） Technical Specification”，目前的版本为1.1，全长160页。P2P技术使得多个Wi-Fi设备在没有AP的情况下也能构成一个网络（P2P Network，也被称之为P2P Group）并相互通信。

Wi-Fi P2P技术是Wi-Fi Display（也称之为Miracast，详情请参考作者的一篇博文http://blog.csdn.net/innost/article/details/8474683）的基础。在Miracast应用场景中，一台支持P2P的智能手机可直接连接上一台支持P2P的智能电视，智能手机随后将自己的屏幕，或者媒体资源传送给电视机去显示或播放。显然，借助P2P技术，Wi-Fi设备之间的直接相连将极大拓展Wi-Fi技术的使用场景。

下面先简单介绍一下P2P的架构。

7.2.1  P2P架构介绍[1]

P2P架构中定义了三个组件，笔者将其称之为一个设备，两种角色。这三个组件分别是：

• P2P Device：它是P2P架构中角色的实体，读者可把它当做一个Wi-Fi设备。
• P2P Group Owner：Group Owner（简称GO）是一种角色，其作用类似于Infrastructure BSS中的AP。
• P2P Client：另外一种角色，其作用类似于Infrastructure BSS中的STA。

相信对本书的读者对上面这三个组件的概念并不陌生。实际上，P2P技术模仿了Infrastructure BSS网络结构：

• 在组建P2P Group（即P2P Network）之前，智能终端都是一个一个的P2P Device。
• 当这些P2P Device设备之间完成P2P协商后，那么其中将有一个并且只能有一个[1]Device来扮演GO的角色（即充当AP），而其他Device来扮演Client的角色。

最终构成的这个P2P Group组织结构如图7-1所示：

图7-1  P2P Group示意图

图7-1展示了一个典型P2P Group的构成，其中：

• 和一个Infrastructure BSS类似，一个P2P Group中只能有一个GO。一个GO可以支持1个或多个（即图中的1:n）Clients连接。
• 由于GO的功能类似于AP，所以周围那些不支持P2P功能的STA也能发现并关联到GO。这些STA被称之为Legacy Clients。

注意：“不支持P2P功能”更准确的定义是指不能处理P2P协议。在P2P网络中，GO等同于AP，所以Legacy Clients也能搜索到GO并关联上它。不过，由于Legacy Clients不能处理P2P协议，所以P2P一些特有功能在这些Legacy Clients中无法实现。

通过上述介绍读者会进一步发现P2P Group和Infrastructure BSS的相似性：

• P2P Device在构建P2P Group时，它将首先通过WSC来获取安全信息。
• 然后，Client将利用协商好的安全设置信息去关联[2]GO（即P2P Group中的AP）。

这部分内容和Infrastructure BSS中STA利用WSC先协商安全信息然后再关联至AP的流程完全一样。正是这种相似性，使得P2P能充分利用现有的一些技术规范。图7-2所示为P2P及其依赖的技术项：

图7-2  P2P及其依赖的技术项

由图7-2可知：

• 为了保证一定的传输速率，P2P要求P2P Device必须支持802.11g及以上的规范。其中，安全部分必须支持WPA2。由于P2P技术一个主要的应用场景就是设备之间共享媒体数据（例如前面提到的Miracast应用场景），所以P2P Device还必须支持WMM（Wi-Fi Multimedia的缩写，它是一种源自802.11e的QoS服务，主要针对实时视音频数据的传输）。
• P2P Client关联到GO之前，需要先通过WSC来协商安全信息，所以WSC也是P2P的依赖技术项。
• 在上述技术基础上，P2P规范定义了一些特有的技术项，图7-2列出了其中三种必须实现的技术项，它们分别是P2P Discovery、P2P Group Operation以及P2P PowerManagerment。除了这三个必选技术项外，P2P规范还定义了一个可选技术项，名为Managed P2P Device Operation（该技术项定义了如何在企业级环境中由对应的IT部门来统一配置和管理P2P设备）。

在如图7-2所示的技术项中，P2P Discovery是P2P所特有的，也是其核心。本章将主要围绕它进行介绍。首先来看P2P Discovery。

7.2.2  P2P Discovery介绍[4]

P2P Discovery的目的很简单，就是使得多个P2P Device能够互相发现并构建一个Group。根据规范，它包括四个主要技术子项：

• Device Discovery：用于P2P设备搜索周围其他支持P2P的设备。
• Service Discovery：该Device Discovery基础上，P2P还支持搜索指定的服务。这部分功能属于可选项，笔者觉得它和第二章2.2.5.1“Apple Bonjour技术介绍”中提到的Bonjour类似。
• Group Formation：用于决定两个P2P Device谁来扮演GO，谁来扮演Client。
• P2P Invitation：用于激活一个Persistent Group（见下文解释），或者用于邀请一个Client加入一个当前已存在的Group。

提示：Group分Persistent（永久性） Group和Temporary（临时性） Group两种。我们举二个简单例子来说明二者的区别：

Temporary Group：当你有份文件要传给一个同事时，双方打开手机的Wi-Fi P2P功能，建立一个Group，然后传输文件，最后关闭Wi-Fi P2P。在这个过程中，GO和Client的角色分配由Group Formation来决定，这一次的GO可能是你的设备，下一次则可能是其他人的设备。对于这种Group，在建立Group过程中所涉及的安全配置信息以及和Group相关的信息（以后我们会见到它）都是临时的，即下一次再组建Group时，这些安全配置信息都将发生变化。

Persistent Group：在这种Group中，GO由指定设备来扮演，而且安全配置信息及Group相关信息一旦生成，后续就不会再发生变化（除非用户重新设置）。Persistent Group中的GO多见于固定用途的设备，例如打印机等。如此，除了第一次通过P2P连接到打印机时相对麻烦一点（需要利用WSC协商安全配置信息）外，后续使用的话，由于P2P设备将保存这些安全信息，所以下一次再使用打印机时就能利用这些信息直接和打印机进行关联了。

由于篇幅关系，本章将仅介绍上述四个知识点中最为基础的Device Discovery和Group Formation，而Service Discovery和P2P Invitation的内容请读者学习完本章后再仔细研读P2P规范。

1.  P2P Device Discovery介绍

P2P Device Discovery虽然也是利用802.11中的Probe Request和Probe Response帧来搜索周围的P2P设备，但其步骤却比Infrastructure BSS中的无线网络搜索要复杂。举一个简单的例子，一个P2P Device除了自己要发送Probe Request帧外，还得接收来自其他设备的Probe Request帧并回复Probe Response帧。而在Infrastructure BSS中，只有AP会发送Probe Response帧。

为了加快搜索速度，P2P为Device Discovery定义了两个状态和两个阶段。

（1）  Device Discovery工作流程介绍

P2P Device Discovery的工作流程包含两个状态和两个阶段。先来看两个状态，它们分别是：

• Search State：在该状态中，P2P Device将在2.4GHz的1,6,11频段上分别发送Probe Request帧。这几个频段被称为Social Channels。为了区别非P2P的Probe Request帧，P2P Device Discovery要求必须在Probe Request帧中包含P2P IE。
• Listen State：在该状态下，P2P Device将随机选择在1,6,11频段中的一个频段（被选中的频段被称为Listen Channel）监听Probe Request帧并回复Probe Response帧。值得指出的是，Listen Channel一旦选择好后，在整个P2P Discovery阶段就不能更改。另外，在这个阶段中，P2P Device只处理那些包含了P2P IE信息的Probe Request帧。

再来看两个阶段，它们分别是：

• Scan Phase：扫描阶段。这一阶段和前面章节介绍的无线网络扫描一样，P2P Device会在各个频段上发送Probe Request帧（主动扫描）。P2P Device在这一阶段中不会处理来自其他设备的Probe Request帧。这一阶段过后，P2P Device将进入下一个阶段，即Find Phase。
• Find Phase：虽然从中文翻译来看，Scan和Find意思比较接近，但P2P的Find Phase却和Scan Phase大不相同。在这一阶段中，P2P Device将在Search State和Listen State之间来回切换。Search State中，P2P Device将发送Probe Request帧，而Listen State中，它将接收其他设备的Probe Request帧并回复Probe Response帧。

图7-3所示为P2P Device Discovery的流程示意图。

图7-3  P2P Device Discovery流程示意图

图7-3所示为两个P2P Device的Discovery流程，其中：

• Discovery启动后，Device首先进入Scan Phase。在这一阶段，P2P设备在其支持的所有频段上都会发送Probe Request帧。
• Scan Phase完成后，Device进入Find Phase。在这一阶段中，Device将在Listen和Search State中切换。根据前面的介绍，每一个设备的Listen Channel在Discovery开始前就已确定。例如，图7-3中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）。图7-3中，Device 1第一次在Listen State中待了2个100TU，而第二次在Listen State中待了1个100TU。
• 当Device处于Find Phase中的Search State时，它将在1,6,11频段上发送Probe Request帧。注意，只有当两个设备处于同一频段时，一方发送的帧才能被对方接收到。

提示：P2P规范对两个状态及两个阶段的描述非常细致，甚至于对每个状态能干什么和不能干什么都有详细说明。不过，从如何快速掌握P2P框架的角度来看，笔者觉得这些内容过于啰嗦。

了解了Device Discovery的大体工作流程后，下面我们将通过实例来看看P2P使用到的Probe Request和Probe Response帧。

转自邓凡平 《深入理解Android：Wi-Fi，NFC和GPS》章节连载[节选]--第七章 深入理解Wi-Fi P2P部分节选,布布扣,bubuko.com

转自邓凡平 《深入理解Android：Wi-Fi，NFC和GPS》章节连载[节选]--第七章 深入理解Wi-Fi P2P部分节选

标签：android   style   blog   http   color   使用   os   io   

原文地址：http://www.cnblogs.com/9420sunshine/p/3922388.html