I sliced my ~20 minute ARAM game packet capture a different way, looking at channel numbers. Enet is a multichannel protocol, it can contain up to 0xff different channels. No idea what guidance there is for using this feature, but here’s what I found. Note that my parser still breaks on some packets, so I discarded things that look malformed or very rare. Ie: report is not 100% complete.
Channel 0xff: control. 2%
Starts the game off with a CONN/VCON pair.
For the whole game, client sends PING roughly twice a second. It gets an ACK about 35-40ms later (my client’s RTT.) A new ping is sent almost exactly 500ms after the last ACK is received.
For the first three minutes, server sends PING roughly twice a second which then client immediately ACKs. Server pings mostly stop after 180 seconds, although I did see a single server PING at 519, 848, 964, 1666, and 1928 seconds.
The PING packets are generally just 12 bytes big, but occasionally are bigger: 30 or 31 bytes is next most common.
Channel 0x03: server to client. 42%
Entirely reliable packets. A whole lot. 54% are small (14 bytes is most common), but some get to 100s of bytes. I imagine this is the important game state.
Channel 0x01: client to server. 35%
This contains all of the traffic the client sends the server. A healthy mix of Enet packet types (reliable, unreliable, and unsequenced). 72% of these packets are very small (14, 24, or 25 bytes). Some are a little bigger.
I ran a second game which was a custom solo game for just 4 minutes with me doing nearly nothing, almost no input. There were almost no reliable packets sent by my client at all; that is consistent with the reliable packets being used for user input. I wonder if all the unsequenced/unreliable traffic is used for bot detection, tracking the user’s mouse position or other signals from the client?
Channel 0x04: server to client. 19%
A bunch of SUNR packets first; those are unreliable but sequenced. Then a stream of SUNS packets; those are unsequenced. No one packet length dominates, the most common is a 40 byte packet at 9%. But almost all the traffic is in the 40-60 byte length.
Channel 0x02: server to client. 1%
Entirely unreliable packets. Not many. 71% are 25 bytes.
Channel 0x05: server to client. 0.03%
This is a mystery. It’s very low traffic, 25 or so over the whole trace. But they’re there and they are sequenced.
Conclusions
I think channel 3 is most interesting as a source of lag; that’s the server sending reliable packets to the client. Channel 1 is also interesting since it contains the clients’ reliable packets to the server.
I just noticed that SUNS packets (unsequenced) still contain sequence numbers. That’s handy for monitoring out of order and loss even if the protocol doesn’t treat those as errors.
I also did a quick spot check of this data vs. a custom solo game I recorded for ~4 minutes where I did almost nothing. The traffic distribution was roughly similar other than the difference in channel 1 I noted above.
Here’s a table of popularity of packet types and channel number.
1469 .4164 PING :ff
1459 .4135 ACKK :ff
299 .0848 ACKK :ff
298 .0845 PING :ff
1 .0003 CONN :ff
1 .0003 VCON :ff
38364 .2362 SUNS :01
8541 .0526 SREL :01
8540 .0526 ACKK :01
967 .0060 SUNR :01
34606 .2131 SREL :03
34217 .2107 ACKK :03
29401 .1810 SUNS :04
1689 .0104 SUNR :04
1510 .0093 SUNR :02
23 .0001 ACKK :05
23 .0001 SREL :05
Nelson's log 