Networking Limits and Best Practices

Some networking nuances to keep in mind when creating networked logic.

Session Limitations

For optimal multiplayer experiences, we recommend no more than 5 users per session, with sessions lasting up to 5 minutes.

Network sessions should last as long as there are users present, however, they’re not designed to be too persistent. We recommend not persisting sessions once all users are no longer present and interacting with the shared environment.

Message Reliability

ARDK does not guarantee 100% reliable messages through the IMultipeerNetworking.SendDataToPeer(s) or BroadcastData APIs. These messages use the TCP transport layer, but there are corner cases where messages can get lost (ex. a device loses internet connection or re-establishes a TCP connection to a server).

Any state information should be written as persistent key-values, as those are guaranteed to get stored on the cloud even with network instability. The data in the key-value store is also guaranteed to be received by all peers in the session, regardless of when they connect.

For reassurance, during an internal test with thousands of sessions, Reliable messages were properly received with 99.95% reliability, and Unreliable messages still had 99% reliability.

Reliable Message Overhead

ReliableOrdered and ReliableUnordered messages cost a lot more overhead to send than UnreliableOrdered and UnreliableUnordered messages. Unless reliability is essential, you should use the UnreliableUnordered transport type for messages.

Furthermore, due to the strict ordering requirement of ReliableOrdered messages, a lost message will prevent all further ReliableOrdered messages from being received. For example, a device that receives messages 1, 3, and 4 (missing 2) will only surface message 1, since it is waiting for a message 2 that may never arrive.

Message Latency

Niantic currently hosts message servers in the US West region. Any server-relayed message will have to make a round trip from your location to the US West servers and back. Users outside the US may experience larger latencies.

Message Size Limits

ARDK comes with some message size limits for its various networking APIs. Attempting to send data over these limits will surface a warning and result in a no-op.

SendDataToPeer(s) and BroadcastData

The size of the byte[] data that can be sent over these APIs is limited to 10MB per message.

StorePersistentKeyValue

The size of the string key is limited to 4KB (when encoded in UTF8) per key. The size of the byte[] value is limited to 100MB per value.

Peer Discovery Race Condition

ARDK uses server-authoritative messages for session management (connected, peer added, peer removed), but uses peer-to-peer messages for sending data between peers in the same session. Due to the physical location of the ARBE (US-West), server messages may have a latency of hundreds or thousands of milliseconds, while peer-to-peer messages may be as fast as tens of milliseconds (depending on device proximity).

It is possible that peer A has received a PeerAdded event for peer B, while peer B has not yet received a PeerAdded event for peer A. During this small gap, if peer A attempts to send a peer-to-peer message to peer B (a valid message from peer A’s perspective), peer B does not yet recognize peer A as a valid peer, and will drop the message.

It is therefore not recommended to send peer-to-peer messages (IMultipeerNetworking.SendDataToPeer(s)) immediately after receiving the PeerAdded event. Instead, schedule any initialization messages to occur a few frames after each new peer is added, to avoid having messages dropped by the receiver.

Reconnecting and Host Leaving

A MultipeerNetworking object can only be used to join one session. After leaving the current session, dispose the existing MultipeerNetworking object and create a new one to join a new session (or rejoin the previous session).

Currently, we do not support rejoining the session as the same peer. If a new MultipeerNetworking object is created, and the same session is joined, the device will be considered a completely new peer.

In the case that the host leaves the session, no new host will be chosen for the session. However, any previously discovered maps will remain until the session times out (all peers leave), and new peers can still localize against the old maps.

After all peers have left a networking session, the session times out after 30 seconds (attempting to rejoin this host-less session before it times out may result in unintended behavior).

Network Ports

ARDK networking uses the following network ports:

  • HTTPS: 8084

  • TCP: 6000-6005

  • UDP: 7000-7005

If you are developing in an environment that uses network firewalls, you may need to adjust your firewall to allow ARDK port ranges in order to test networking in your app.