Table 5.1: Client-server traffic depending on the <strong>to</strong>tal number <strong>of</strong> playersClientServer# Players Total (B/s) Up (B/s) Down (B/s) Total (B/s) Up (B/s) Down (B/s)2 7,511 4,514 2,997 14,933 5,955 8,9783 5,513 3,510 2,002 16,799 6,072 10,7274 6,518 4,649 1,869 26,030 7,440 18,5916 12,080 9,161 2,919 71,592 15,758 55,8348 16,805 13,328 3,477 131,114 24,210 106,90312 22,405 19,191 3,213 269,093 38,355 230,73816 26,834 23,594 3,240 427,596 53,215 374,38124 47,501 43,044 4,457 1,139,158 112,402 1,026,75632 63,338 58,788 4,551 2,012,340 142,783 1,869,557shooting. The incoming bandwidth grows linearly <strong>with</strong> the number <strong>of</strong> players because each client receivedthe updates <strong>of</strong> all others. The server’s traffic measurements show why the number <strong>of</strong> players islimited <strong>to</strong> less than 40. With 32 players, the average outgoing traffic already reaches about 20MB/s,and, more importantly, its growth is quadratic. The time-traffic plots 5.3 and 5.4 show the same picture.Despite any potential optimization, the server’s work always increases quadratically <strong>with</strong> the number <strong>of</strong>players (<strong>of</strong> which everyone can see all others) that it has <strong>to</strong> serve. Message aggregation will help <strong>to</strong> significantlyreduce the outgoing traffic, but it will not change the complexity. A possible countermeasure is<strong>to</strong> reduce the level <strong>of</strong> detail <strong>of</strong> update messages depending on the load, e.g., by decreasing the frequency<strong>of</strong> outgoing update messages.5.1.2 <strong>Peer</strong>-<strong>to</strong>-<strong>Peer</strong>The peer-<strong>to</strong>-peer implementation using the slightly adapted pSense algorithm, which is run in the simula<strong>to</strong>r,supports much larger numbers <strong>of</strong> players than the simple client-server version. For limiting simulationtime and memory requirements, the measurements are set <strong>to</strong> a maximum <strong>of</strong> 64 and 128 playersrespectively for the two measurements.The peer traffic (table 5.2, figures 5.5 and 5.6) shows a quadratic growth <strong>with</strong> the number <strong>of</strong> playersin the vision range, equally for both upstream and downstream. This behavior evidently results from thefact that in the simple scenario each player sends its updates <strong>to</strong> everyone else and also receives updatesfrom everyone. Because <strong>of</strong> the different message formats, the peer-<strong>to</strong>-peer traffic cannot be compareddirectly <strong>with</strong> the client-server version. The binary peer-<strong>to</strong>-peer position update messages have a fixed size<strong>of</strong> 64 bytes while client-server messages are variable in size, <strong>with</strong> an average position update messagesize <strong>of</strong> around 50 bytes. With 32 players, the resulting traffic in each direction is around 100KB/s whichcan be seen as an upper bound for upstream bandwidth <strong>of</strong> <strong>to</strong>day’s internet connections. A client in theclient-server version requires far less bandwidth. But as for the client-server version, there is still a greatpotential <strong>of</strong> optimization for traffic reduction. The pSense algorithm describes a forwarding technique<strong>to</strong> disburden weak nodes which has not been implemented, and Donnybrook introduces different levels<strong>of</strong> update accuracy.72 5.1 Networking Measurements
70,00060,00050,000Traffic (bytes/s)40,00030,00020,000TotalDownUp10,00000 5 10 15 20 25 30 35# PlayersFigure 5.1: Client traffic depending on the <strong>to</strong>tal number <strong>of</strong> players2,500,0002,000,000Traffic (bytes/s)1,500,0001,000,000TotalDownUp500,00000 5 10 15 20 25 30 35# PlayersFigure 5.2: Server traffic depending on the <strong>to</strong>tal number <strong>of</strong> players5 Evaluation 73
Change language