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

本章主要内容:

  • 介绍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和Miracast,智能终端设备之间的多屏共享和互动功能将很快得以实现。另外,恰逢本章撰写之际,Google发布了Android 4.3。在这次发布盛会上,Google推出了ChromeCast设备。目前,ChromeCast的技术实现细节还不清楚,据说有可能是Google自己定义的Google cast协议(可参考developers.google.com/cast)。

下面先简单介绍一下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。

提示:

1、P2P Group Operation讲得是GO如何管理一个Group,也就是GO的工作职责。这部分内容请读者自行学习参考资料[2]一节。

2、P2P PowerManagement和P2P设备的电源管理有关,用于节省不必要的电力损耗。由于篇幅关系,本章不拟讨论它。请感兴趣的读者自行学习参考资料[3]。

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帧。

[1]假设这设备将只组成一个P2P Network。

[2]注意,此处的关联指得是RSNA,其工作流程包括包括4-WayHandshake。

Android Wi-Fi Display(Miracast)介绍

http://blog.csdn.net/innost/article/details/8474683

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

时间: 2024-10-08 11:04:36

转自邓凡平 《深入理解Android:Wi-Fi,NFC和GPS》章节连载[节选]--第七章 深入理解Wi-Fi P2P部分节选的相关文章

[深入理解Android卷二 全文-第七章]深入理解ContentProvider

由于<深入理解Android 卷一>和<深入理解Android卷二>不再出版,而知识的传播不应该因为纸质媒介的问题而中断,所以我将在CSDN博客中全文转发这两本书的全部内容 第7章  深入理解ContentProvider 本章主要内容: ·  深入分析ContentProvider的创建和启动,以及SQLite相关的知识点 ·  深入分析Cursor query和close函数的实现 ·  深入分析ContentResolver openAssetFileDescriptor函数

[深入理解Android卷一全文-第七章]深入理解Audio系统

由于<深入理解Android 卷一>和<深入理解Android卷二>不再出版,而知识的传播不应该由于纸质媒介的问题而中断,所以我将在CSDN博客中全文转发这两本书的全部内容. 第7章  深入理解Audio系统 本章主要内容 ·  具体分析AudioTrack. ·  具体分析AudioFlinger. ·  具体分析AudioPolicyService. 本章涉及的源代码文件名称及位置 以下是本章分析的源代码文件名称及其位置. ·  AudioTrack.java framewor

Android深度探索(卷1)HAL与驱动开发 第七章&#160;LED将为我闪烁:控制发光二极管 读书笔记

本章的实验将会实现真正意义上的Linux驱动,会实现直接与硬件的交互.需要控制4个LED灯. 7.1LED驱动的实现原理 事实上并不是Linux驱动直接向硬件中的内存写数据,而是与本机的I/O内存进行交互.I/O内存是通过各种接口连接到主机的硬件在主机内存中的映射. 7.2编写LED驱动 1.创建LED驱动的设备文件 (1).使用cdev_init函数初始化cdev (2).指定设备号 (3).使用cdev_add函数将字符设备添加到内核中的字符设备数组中. (4)使用class_create宏

ANDROID深度探索(卷1)HAL与驱动开发 第七章

并不是 Linux 驱动直接向硬件中的内存写数据, 而是与 本机的 I/0 内存(I/O Memory,位于内核空间进行交互.所谓 1/0 内存是通过各种接口( PCI. USB.蓝牙.以太网口等〉连接到主机( PC.手机〉的硬件〈网卡.声卡.摄像头等〉在主机内 存中的映射.例如,在 Ubuntu Linux 上运行的驱动只需要访问运行 Ubuntu Linux 的主机中的 I/o 内存即可,然后 Linux 内核会利用 I/0 内存中的数据硬件交互. Linux 内 核的内存管理模块负责同步

(深入.Net平台和C#编程)第七章-深入理解多态.上机练习.20170412

1 //=================父类=================// 2 using System; 3 using System.Collections.Generic; 4 using System.Linq; 5 using System.Text; 6 using System.Threading.Tasks; 7 8 namespace Sj2.Entity 9 { 10 /// <summary> 11 ///父类 :工作类 12 /// </summary&

Android深度探索(卷1)HAL与驱动开发第七章总结

本章学习了搭建S3C6410开发板的测试环境,主要都是围绕S3C6410开发板进行的.这个开发板是由三星公司推出的一款低功耗.高性价比的RISC处理器,基于ARM11的内核.一.搭建编译环境所需要的交叉编译工具链:S3C6410X Tool Chain 4.2.2 - EABI V0.0 - cross-4.2.2-eabi.tar1.解压上述工具链获得文件夹:4.2.2-eabi/2.在/usr/local/下面创建目录arm/ (注意,最好是放到这个目录,不然在以后的编译过程中可能出现一些错

第七章 深入理解多态

1.里氏替换原则: 在一个软件系统中,如果子类能替代父类出现的位置,而对整个软件的功能没有任何影响,那么就称为里氏替换原则 2.实现面向对象的多态性有哪几种方法? 总共有3种, 第一种,虚方法实现多态,  第二种:抽象方法实现多态  第三种:接口实现多态 目前为止,我们学了两种: 第一种:虚方法实现多态 通过在普通类Person中用Virtual关键字定义虚方法SayHello(),然后在子类Student中通过override关键字对父类的SayHello()方法进行重写. 第二种:抽象方法实

Android深度探索(卷1)HAL与驱动开发 第七章 LED将为我闪烁:控制发光二极管

第七章  LED将为我闪烁:控制发光二极管 读书心得    LED驱动的实现原理 尽管Linux驱动程序直接与硬件打交道,但并不是Linux驱动直接向硬件中的内存写数据,而是与本机的I/O内存进行交互. 编写LED驱动 测试LED驱动 LED驱动的移植 在修改Linux驱动的源代码时,应尽量不要修改Linux驱动的借口. LED驱动是本书第一个真正和硬件打交道的Linux驱动,虽然LED驱动并不复杂,只是控制了四个LED,但是LED驱动已经包括了Linux驱动所有必要的部分.一个完整的Linux

深入理解Android系列书籍资源分享更新

因为版权问题,出版社不能分享电子版.我从一些"爱"书的朋友们自己扫描后得到的PDF电子版里,下载了2个比较清晰的版本分享给大家 http://t.cn/RL18RVo?u=1826440077&m=3875729874015740&cu=1826440077 BTW,我一直觉得窃书不算偷,只要愿意分享出来.这年头,哪里有什么从头到尾都是原创的知识呢 由于115网盘限制礼包下载,我现在将深入理解Android系列书籍或其他资源转移到百度网盘上, 供兄弟姐妹们下载分享. 0