Networking Limits and Best Practices
Some networking nuances to keep in mind when creating networked logic.
On This Page
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.
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
In order to make messages as reliable as possible, there is substantial overhead to sending messages of type
ReliableOrdered. Unless it is essential that a message is sent over a Reliable protocol, it is recommended that the Unreliable protocols are used instead.
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 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.
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).