Nelson's log

LoL protocol: channels

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