## 3 Materials and Methods
### Trace Anonymization  
Game \(A\) carries session information in its application messages. A new session identifier is assigned when a player authenticates themselves with the server. This includes cases where the mobile game application wakes up from an extended period of inactivity, as well as situations where a new player connects to the game servers. Although the session identifier used by Game \(A\) is in the UUID form, it is already an ephemeral, opaque handle that identifies a matching player and does not reveal any privacy information. Thus, the company did not perform any additional anonymization process, as illustrated in Listing 1. ```
10f0 20:0(11:55380B) 12031 session_message_utils.cc:001] [C-3] [C-3] [TOV/Protudof: type-,IITF20030, length=03, session=fa781919-4454-4709-8472-cf684754230]
10f0 20:0(11:555380B) 12030 session_message_utils.cc



### Log Processing

Due to the large size of the logs and the numerous player sessions, we first grouped the log files by the player's session identifier. For Game \(A\), we used the session identifier information in the log file as it is, while for Game \(B\), we employed a tuple of a hashed IP address and a port number. This approach not only helped in organizing the data more efficiently but also ensured the preservation of session continuity and player behavior patterns for accurate analysis. To analyze packet lengths, we classified them by traffic direction and accumulated the statistics over all player sessions. This classification allowed us to observe the differences in data flow between incoming and outgoing traffic, providing insights into the server-client interaction dynamics. For packet inter-arrival times, we measured the inter-arrival time for each direction per player session, and then computed the statistics per direction. Further, we segmented Game _B_'s data based on different time frames in 1 h granularity and game events to understand how player behavior and server responses varied under different conditions. This temporal analysis was pivotal in understanding the scalability of the game servers during peak and off-peak hours. Lastly, we organized packet arrivals into 100-millisecond time slots and used this information to create variance-time plots by calculating variances as the bucket aggregation level increased. The analyzed results are presented and discussed in the following section. The source code used for log processing is available through the author's GitHub repository: [[https://github.com/dkmoon/2023](https://github.com/dkmoon/2023) trace_analysis]([https://github.com/dkmoon/2023](https://github.com/dkmoon/2023) trace_analysis) (accessed on 7 February 2024). This repository includes all the scripts and methodologies used, ensuring transparency and reproducibility of our analysis. ## 4 Results and Discussion

### Packet Lengths

Each of Game _A_'s log entry records a corresponding application message (i.e., Protocol Buffers message) length. Thus, it does not count the lengths of the IP header and the TCP header. On the other hand, Game _B_'s log is generated by the AWS ELB and it includes an HTTP header as well. Figures 1 and 2 illustrate the distributions of measured packet lengths. Because an HTTP header is an inevitable part of network traffic, for games like Game \(B\), to carry application messages, we did not exclude the HTTP header length. Also, this approach helps us compare the packet lengths at the TCP-level regardless of the underlying networking topology. Figure 1: Packet lengths distribution for Game \(A\) (mobile MMORPG). The graphs illustrate the lengths of data in TCP payload. According to Game _A_'s measurement, mobile MMORPGs are observed to use very short packets (Figure 1); regardless of traffic direction, most application messages are less than or equal to 100 bytes long. Considering traffic direction, server-to-client traffic pattern reveals a much longer tail, while client-to-server traffic shows a handful of packets are dominant. In the measurement, 81.9% of client-to-server packets were 44 bytes long.