|
To further examine the traffic characteristics of of a game on Colyseus, we examine how bandwidth usage varies over time. Figure 9 (a) and (b) show the outbound bandwidth used by the median node in Colyseus over a 5 minute period of the trace in the edge-server and peer-to-peer scenarios, respectively. For comparison, we also plot the traffic characteristics at the server of the client-server architecture and the same node in the broadcast architecture. In all architectures, the traffic is significantly variable across time. This reflects the variable nature of gameplay and the fact that game traffic is coupled with the number of visible objects seen by each player when update traffic dominates. In client-server architectures, this variability is usually dealt with by artificially capping the number of objects that can be sent to each client at a time based on an application defined priority ordering. The same solution could be used to limit update traffic in the other two architectures.
Figure 9 (c) and (d) zoom into the Colyseus bandwidth usage time sequence and break down the cost between update traffic and Mercury routing and matching traffic (for the edge-server and peer-to-peer scenarios, respectively). In the edge-server scenario, the game update traffic dominates the traffic profile, despite the fact that there are still some bursts in the Mercury traffic. However, in the peer-to-peer scenario, since there is only one player per node, bursts in Mercury traffic dominate the traffic profile. The majority of these bursts occur when many publications are matched with many subscriptions at the node; i.e., when many objects enter the region of the game world corresponding to the node's range in the Mercury ring. We believe that these bursts can be mitigated by distributing the cost of delivering matched publications among the receivers at the expense of a little latency, since many receivers become interested at almost the same time.