The history of creating a library for group communication of android devices via Wi-Fi Peer-to-Peer connection

Background

The motivation for writing this application was the term paper on the discipline "Computer Systems and Networks." Honestly, this is one of the most unloved sides in computer technologies, and I decided to "tailor" the course project to my interests, namely, Android development.

It was decided to create a library for connecting Android devices using Wi-Fi Direct technology and transferring data between them (Wi-Fi Peer-to-Peer connection is carried out just using Wi-Fi Direct technology).

Why Wi-Fi Direct?

After approving the idea of ​​connecting devices locally, the question arose before me: What technology am I going to implement this with? The following options were considered:

• Bluetooth
• Wi-Fi Hotspot
• Wi-Fi Direct or Wi-Fi Peer-to-Peer

Bluetooth

The main disadvantages of this approach are the restriction of users on the same network and the small radius of action. I want to create a group of devices that communicate with each other at a distance of at least 10 meters.

Wi-Fi Hotspot

Creating an access point is not a bad option, but I am confused by the situation with the loss of the main Wi-Fi connection. I would like users to be located on the local network, and at the same time have access to the global, for example, be connected to their home router.

However, using Wi-Fi Hotspot, you can achieve maximum data transfer speed ( Portal , SHAREit applications ).

Wi-Fi Direct or Wi-Fi Peer-to-Peer

This approach solves all the above problems:

1. unlimited number of clients (if not, please correct me)
2. long range
3. Wi-Fi connection to devices without creating an access point
4. technology supported with API 14 (Android 4.0)

But immediately a doubt creeps in, they say Wi-Fi Peer-to-Peer, while we are going to create a group with the owner and the customers, and even more so that everyone communicates with each other. This is precisely the main reason for writing this article.

Wi-Fi Aware

This option was not mentioned in the main list, because I do not think that he can fully fit for the task. However, Wi-Fi Aware is a relatively young technology for sending messages within a certain range.

Let's start with the problems.

Frankly, the documentation provided by developer.android.com was not easy for me. And I started looking for samples. After going through a bunch of material, I came across the most interesting sample by Google .

I never thought that on the official website from Google you can find shit, but this is just the case. However, even this should be given credit, because thanks to this resource I realized what I wanted.

The sample demonstrates an example of a chat of two devices that found each other in a list showing nearby Wi-Fi Direct devices with the chat application running. When you select a partner, ChatActivity opens directly.

A very important point is the search for interlocutors: Wi-Fi Direct devices such as a TV or any headset will not be displayed in the list. Only devices running the Chat application are displayed.

There was also a problem with testing. It was necessary to test the performance of the application exclusively on real devices.

What was implemented to demonstrate the health of the library

The application presents the following functionality:

1. choice of role in the process of working with the application (for example, “Mafia” and “Peaceful” were created)
2. group creation
3. joining an existing group
4. communication between devices (when a button is pressed, its color changes both for the initiator and for all others corresponding to the current role (or broadcast))

Description of screens from left to right:

• start screen with a choice of action and role
• list of devices that joined the current group owner
• list of active groups to join
• application settings (device login, group name, password to enter the group)
• "Game" screen

After the user selects which group to join, the group owner receives a message about establishing communication with this device.

The basic concept of the library

The logic is based on client-server architecture. The server is the owner of the group, clients are connected users.

The application has its own Serializer / Deserializer for converting the transmitted data into an array of bytes and vice versa. The following information is stored in the transmitted data:

• to whom to send (mafia, civilians, everyone)
• what kind of data (for example: changing the color of a button)
• data itself (serialized Object)

The first paragraph “to whom to send” is not entirely correct, because data is sent to everyone. First, to the server, then the server sends this packet to all clients. But the client himself decides whether he should process this data or not. This is done for the simple reason that the server does not know the roles of its clients. Thus, equality was achieved in the group. The owner differs from everyone else only in that he was burdened with the transfer of data to all his clients.

Library components

• WifiDirectManager - the main class of the library; He is responsible for creating a group, searching for devices, joining a device to a group or invitation to it, sending a data packet to all members of the group
• WifiP2pDeviceObservable - implementation of the Observable pattern; when a Wi-Fi Direct device is found, notifies the observer
• WifiDirectBroadcastReceiver is engaged in notifying the application about changes in Wi-Fi Direct connection (for example: whether the connection with another device has been successful), the Wi-Fi status on the device (for example, disconnection should be followed by a warning to the user about the application not continuing to work)
• MessageShaper is responsible for serialization / deserialization of transmitted data; when deserializing the output, we get an object of the type android.os.Message (obj is the object, what is the object for what purpose (for example: change the color of the button), arg1 is the type of access (for the mafia, civilians, or broadcast))
• Serializer is directly involved in serializing / deserializing objects
• Status - characterizes each device as the owner of the group or client
• ChatNeedle stores a socket through which two devices are connected; handles input / output data streams; the client has only one ChatNeedle - with the owner, while the owner has their number equal to the number of customers
• Member - a class that describes a group member (not himself) for further use in a game scenario; stores ChatNeedle to connect with this group member
• MemberList - a class that stores all the devices with which our device is connected; in the case of the group owner, all customers, in the case of the client, the owner
• GroupOwnerSocketHandler is used by the group owner to open a specific number of sockets to which clients connect.
• ClientSocketHandler is used to establish a client connection with the group owner

The most difficult problem during development

When the project reached the stage of testing the multiplayer (> 2 devices), then the heat started. The two devices, as before, were connected without problems (for which purpose the Wi-Fi Peer-to-Peer was created), however, when the third link was connected, there was almost always a trash. When you click on the button with the "owner" (later you will understand why in quotation marks) the color changed only for the client with whom the "owner" last talked.

After long and hard hours of thought, I decided to connect the devices via the Wi-Fi Direct option in everyone’s Wi-Fi settings, and I noticed a thing that turned my mind around and added just one line to the method code to establish the connection.

Prior to that, I thought that the device that connects to another will always be a client ... and this is far from the case. When connecting devices, the owner’s rights were randomly transferred to one of them, which prompted me to search for a config'a setting that would fix this situation and make the connected device a client.

When connecting two devices, a special config is written, which contains:

• address of the device we want to join
• wps.setup allows you to set how we will connect: with a password or simply by pressing a button
• groupOwnerIntent - here it is (caught!), the one who solved my problem; an integer field whose value varies from 0 to 15 (0 - we want to be a client, 15 - we want to be the owner); by default -1, which gives the system the right to choose the role in this regard

        final WifiP2pConfig config = new WifiP2pConfig();
        config.deviceAddress = deviceAddress;
        config.wps.setup = WpsInfo.PBC;
        config.groupOwnerIntent = status.getIntent();
        mWifiP2pManager.connect(mWifiP2pManagerChannel, config, null);

Status (enum) above is the current position of the device, if it is the creator of the group - GroupOwner, otherwise - Client.

Necessary improvements

While there is no solution to the problem of reconnecting. For example, when you exit the application, for example, to make a call, after returning, we are waiting for ... nothing. After the deterioration of activity, it is necessary again to pull up the customers themselves, and the customers - the owner.
I would also like to introduce the concept of transferring the owner’s rights to one of the clients in case the group owner needs to leave the game.

Protection. To enter a specific group, it would be nice to implement authorization.

Conclusion

I don’t think that I have implemented something new or revolutionary, but this project served as a good example of the extraordinary use of Wi-Fi Peer-to-Peer connections. I have successfully built a network between devices using Wi-Fi Direct, which allowed me to freely communicate between them.

This is my first article, so judge strictly. Thanks for attention.

→ Link to GitHub
(the wifidirect module can be easily transferred to any android project)