Open-source multiplayer game server compatible with the RuneScape client
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
openrs2/share/doc/protocol/overview.md

2.6 KiB

Protocol overview

The RuneScape protocol runs on top of the Transmission Control Protocol (TCP). As TCP is stream-oriented, a framing scheme is required to determine where one packet ends and where the next begins. RuneScape primarily uses a type-length-value (TLV) scheme for framing, though some exceptions do exist - for example, the JAGGRAB and JS5 protocols use different framing schemes.

A RuneScape connection may be in several states, each of which has a different set of opcodes (types in TLV parlance). Opcodes may have different meanings in different states. Opcodes may be optionally encrypted with the ISAAC stream cipher.

All connections start in the login state.

Types

There are three types of packets:

  • Fixed length - supports any payload length, including no payload.
  • Variable length (byte) - supports up to 255 bytes of payload.
  • Variable length (short) - supports up to 65,535 bytes of payload in theory, though in practice the client's receive buffer limits the payload to 5,000 bytes in the 550 build. This limit is raised by OpenRS2's client patcher.

They are structured as follows:

Fixed length

Data type Description
UnsignedByte Opcode
Byte[len] Payload

Variable length (byte)

Data type Description
UnsignedByte Opcode
UnsignedByte Length (len)
Byte[len] Payload

Variable length (short)

Data type Description
UnsignedByte Opcode
UnsignedShort Length (len)
Byte[len] Payload

Opcode encryption

Opcodes are encrypted by adding the opcode to the next 32-bit output from the ISAAC random number generator and truncating the result to 8 bits. Decryption is the same process in reverse: the 32-bit output is subtracted from the encrypted opcode, and then the result is truncated to 8 bits.

There are two ISAAC random number generators: one used for upstream (client -> server) traffic and one used for downstream (server -> client) traffic. Both are initialised with a seed consisting of four 32-bit integers.

The upstream seed is the same as the downstream seed, except each integer component is incremented by 50.

The seed is negotiated during the login process. Before it is negotiated, opcodes are not encrypted.