Android Wifidirect Learning (iii) Some basic knowledge and questions

Introduction to Peer Architecture

Three components, one device, and two roles are defined in the peer-to architecture. These three components are:

• Peer device: It is the entity of the role in the peer-to-peer architecture that readers can think of as a Wi-Fi device.
• Peer group Owner (GO): A group is created when a peer network is created.
• Peer Group Client (GC):

• The smart terminal is a one-to-peer Device before the peer Group (that is, the peer Network) is formed.
• Once the peer-to-peer negotiation between these devices is complete, there will be one and only one device to play the role of Go, while the other device plays the role of GC.

The final form of this peer group structure:

Peer Group

Shows the composition of a typical peer group, where:

There can only be one go in a peer group. A go can support 1 or more GC connections (that is, the 1:n in the diagram).

• Because go functions like an AP, the Wi-Fi STA, which does not support peer-to-peer functionality, can also be found and associated to go. These WiFi STA is called Legacy Clients.

Note: A more accurate definition of "do not support peer-to-peer" refers to the inability to process peer-to-peer protocols. Go is the same as the AP, so legacy Clients can also search for go and associate it with the peer network. However, because Legacy clients cannot handle peer-to-peer protocols, some of the unique features of peer-to legacy cannot be implemented in these clients.

The approximate pairing process for Wifi_direct is as follows: A. wifip2pmanager.discoverpeers () Start scanning the device B. Get the scanned device, select one of the devices to connect to the pairing Wifip2pmanager.conne         CT c. After pairing succeeds, connect according to Wifip2pinfo.isgroupowner and Wifip2pinfo.groupowneraddress. The flowchart is as follows:

Common problem issues with 1:wifip2pmanger.connect (), how to determine who is go, who is a GC

A: When you call Wifip2pmanger.connect () to make a connection, go also calculates that the GC identity is random. The developer cannot decide which device groupowner is, but it can be suggested by wifip2pconfig.groupownerintent parameters.

Question 2: What to do if you must determine who is going, who is the GC

A: The first step: Go side First call Wifip2pmanger.creategroup

Step two: Go or GC side call Wifip2pmanger.connect

That is: group first, then connect

Issue 3: How to Disconnect

Answer: Wifip2pmanger.removegroup

Note: The wifip2pmanger.removegroup is removed from group and disconnected. Wifip2pmanger.cancelconnect () Disconnects a connecting connection, that is, the current state is invited.

Question 4: We know that pairing is successful: both devices that are paired must be able to scan to each other. So how to ensure that the computer has been in the search state?

A: After testing that, in general, the local scan, to be able to stay online for 3 minutes, that is able to search for other devices/by other devices to search the time is generally 3 minutes. But this 3 minutes is not very accurate, which is related to mobile phone performance or WiFi chip. So the solution we can do is to restart the search if the search is over.

For the general peer DISCOVERY, if the search is over, you will receive a broadcast wifip2pmanager.wifi_p2p_discovery_changed_action so that you can re-search again after receiving the broadcast.

For service discovery (which is actually the most widely used), when the search is over, the system does not issue a broadcast notification, which poses a challenge to the developer: you cannot know whether you are currently in a search (visible) state.

At present, it is more feasible to restart the search every 3 minutes (or less), so that the machine is always in the search state. However, this can only cover most cases, and it is recommended that you then add a manual search (not found to allow the user to search manually) to ensure the current visibility.

At present wifip2p is still not very stable, from the test results, the performance of Wifi_direct by the specific equipment, the speed of pairing is also very different, from 10 seconds to 2 minutes or even longer. May appear

The A.A machine is in the search (visible) state, but the B machine still cannot be searched;

B. There is also the possibility that a machine is in the search (visible) state, b machine also searched, but the connection failed (the main reason for this situation is because a machine after the end of the system is not notified, and B machine is currently searching for a machine is the state of a machine)

Reference article:

Android platform Wifi_direct using http://blog.csdn.net/a220315410/article/details/9114653

"In-depth understanding of ANDROID:WI-FI,NFC and GPs" http://blog.csdn.net/innost/article/details/21555957

Android Wifidirect Learning (iii) Some basic knowledge and questions