As of April 2023 Peer-to-Peer Networking is deprecated and is no longer included in the list of available Platform APIs for integration. For more information check the blog post here.

Third-party solutions, such as Photon, can be used as an alternative to implement P2P networking in your app. For an example of how Photon, and other third-party solutions integrate with the Platform API, check here.

Peer-to-Peer (P2P) networking allows your app to establish a connection and send data directly between users.

There are a number of uses for P2P networking. Some common implementations include, using P2P to exchange chat messages between users, updating gameplay data in lower latency, or update avatar positions in real-time. Our P2P service connects users to exchange data directly.

The Meta Horizon platform P2P allows you to choose between two send policies to transmit data depending on your use-case and the needs of your app.

Reliable connections transmit data that will be delivered once and in the order that messages are sent. The networking layer retries until each message is acknowledged by the peer. Outgoing messages are buffered until a working connection to the peer is established. Reliable messages are useful when using P2P to send text chat messages that need to be delivered once and in the order that the user sent them, but not necessarily instantaneously.

Unreliable connections transmit data as best-effort, but cannot guarantee delivery in a specific order or time-frame. Any messages sent before a connected state is established will be dropped. Unreliable messages are useful when you’re using P2P to update game data in realtime and transmitting data quickly is more important than guaranteeing delivery once and in order. Note that messages sent over unreliable connections should be limited to 1200 bytes.

Note

P2P data may be routed through relay servers located inside Meta's infrastructure when connecting to client devices that are behind network address translation (NAT), if a connection cannot be established from their detected external address. The VoIP data passing through a relay server is not inspected any more than is necessary to forward to the recipient; nor is it retained.

This is a Platform SDK feature requiring Data Use Checkup

To use this or any other Platform SDK feature, you must complete a Data Use Checkup (DUC). The DUC ensures that you comply with Developer Policies. It requires an administrator from your team to certify that your use of user data aligns with platform guidelines. Until the app review team reviews and approves your DUC, platform features are only available for test users.

Integrate Peer-to-Peer Networking

The following methods are available to call from your client app.

Establish a connection:

ovr_Net_Connect()

This sends a ovrMessage_NetworkingPeerConnectRequest to the specified user. It returns a ovrMessage_NetworkingPeerConnectionStateChange notification when the connection is established, you’ll need to be listening for this notification.

Accept and open a connection:

ovr_Net_Accept()

This should be called after receiving a ovrMessage_NetworkingPeerConnectRequest message.

Accept and open a connection for a room:

ovr_Net_AcceptForCurrentRoom()

Accept connection attempts from members of the current room. Please see the Rooms page for information about creating and joining rooms. Returns false if the user currently isn’t in a room.

Check a connection with a user:

ovr_Net_IsConnected()

Checks if the current users is connected to another specific user, returns a true or false.

Ping a user:

ovr_Net_Ping()

Ping a user to determine network connection quality.

Send data to a user:

ovr_Net_SendPacket()

Send a sequence of bytes to a specified user. You also specify the length of the packet, the packet contents in bytes and the policy to apply to the packet; whether the connection is reliable, unreliable or unknown. The specified length must be less than or equal to the allocated length of the bytes. For a reliable connection, the max number of bytes allowed in the packet is 65535 bytes, which includes any descriptive information (headers) as well as the user data. If the connection is unreliable or unknown, the recommended max size is 1200 bytes. A new connection to userID will be established (asynchronously) unless one already exists.

Send data to a room:

ovr_Net_SendPacketToCurrentRoom()

Sends a packet to all members of the room, excluding the currently logged in user. You specify the length of the packet, the bytes in the packet and the policy to apply to the packet; whether the connection is reliable, unreliable or unknown. For a reliable connection, the max number of bytes allowed in the packet is 65535 bytes, which includes any descriptive information (headers) as well as the user data. If the connection is unreliable or unknown, the recommended max size is 1200 bytes. The room has to be created or joined by calling one of the room/matchmaking functions. This function returns false if the user currently isn’t in a room.

Read a data packet:

ovr_Net_ReadPacket()

Read the next incoming data packet. The return handle will point to an object that represents some data read from the network. This returns the ovrMessage_ReadPacket message type. Use ovr_Packet_GetSenderID() to get the sender ID, ovr_Packet_GetSize to get the size of the packet, or ovr_Packet_GetBytes to get the contents of the packet.

Release the data packet from memory:

ovr_Packet_Free()

Once the message has been read, release the packet and free the memory used by the packet.

Close a connection:

ovr_Net_Close()

When the session is complete, close the connection.

Close a connection for a room:

ovr_Net_CloseForCurrentRoom()

Close the connection with everyone in the current room. Call this before leaving the room.

Listening for Messages

Integrating Peer-to-Peer networking involves handling the notifications that are sent as part of the networking process. These notifications could be connection requests and notifications that the state has changed. Please review the Requests and Messages page for more information about how notifications work in the Platform SDK.

Specifically, for P2P you should be listening and able to handle the following notifications:

ovrMessage_Notification_Networking_ConnectionStateChange

ovrMessage_Notification_Networking_PeerConnectRequest

ovrMessage_Notification_Networking_PingResult

Example Implementation

In general, a P2P connection between two users, users A and B, would follow:

Initiate a connection between two users. Explicitly connecting users by calling ovr_Net_Connect() ensures that all packets will received. You can skip this step and allow the service to implicitly connect when the first packet is received. Unreliable messages received before a connection, and a state change to ovrPeerState_Connected, is established may be dropped.

User A sends a connection request by calling ovr_Net_Connect() with the user B’s userID.

User B calls ovr_Net_Accept() to accept and initiate the networking session.

Both users receive the ovrMessage_NetworkingPeerConnectionStateChange notification that the state has changed to ovrPeerState_Connected. User A can now call ovr_Net_SendPacket() to send the message or data. When calling ovr_Net_SendPacket() you’ll define one of the policies described above, reliable or unreliable. Please see ovrSendPolicy for more information.

User B’s application parses the message using ovr_Net_ReadPacket() and ovr_Packet_GetBytes(). The application frees the memory used by the message on both clients with ovr_Packet_Free().

(Optional) Destroy the connection by calling ovr_Net_Close(). The SDK manages the pool of connections and will discard unused connections.

The following example comes from the VRVoiceChat Sample App, a Unity app that uses P2P to transmit real-time avatar location and movement of other users.

More information about Avatars can be found in the Avatar SDK documentation.

Did you find this page helpful?