- 1 Login Protocol
- 1.1 Variables:
- 1.2 Login Process:
- 2 Game Protocol
The login is comprised of four stages in which the client and server switch in regards to which one is reading and which one is writing.
The login process has a lot of variable data, compiled here is a list of the variables and their different values.
A hash of the player name, thought to be used to select an appropriate login server. This has no use in current private servers.
Server Session Key
The server-session-key is one of two ciphers used to encrypt the game protocol, using the ISAAC algorithms.
"Data File Version"
Unknown, quoted from a Winterlove private server.
The ID of the user.
The username of the player, used to identify their account.
The password of the player account, used so only they can log into their account.
Client Session Key
The client-session-key is one of two ciphers used to encrypt the game protocol, using the ISAAC algorithms.
The status of the connection.
|16||Signifies that the connection is new.|
|18||Signifies that the session is reconnecting a previously lost connection.|
The size of the unencrypted login packet, used to determine how many bytes need to be read from the stream by the server.
The memory-version of the game client.
|0||Signifies the client is a low-memory client.|
|1||Signifies that the client is a high-memory client.|
9 4-byte values, Each containing the CRC of their respective cache files. Used by the server to verify client is up to date.
The in-game player status - player, player moderator, or administrator.
|0||Signifies that this player is a normal player.|
|1||Signifies that this player is a player moderator.|
|2||Signifies that this player is an administrator.|
If set to 1, information about mouse movements etc. are sent to the server. Suspected bot accounts are flagged.
At the beginning and end of the login procedure, we send different values to the client to allow or deny a login. The various values show different messages on the login box on the client or do something internally.
|-1||Waits for 2000ms and tries again while counting failures.|
|0||Exchanges session keys, player name, password, etc.|
|1||Waits for 2000ms and tries again.|
|2||Client made a successful login.|
|3||"Invalid username or password."|
|4||"Your account has been disabled. Please check your message-center for details."|
|5||"Your account is already logged in. Try again in 60 secs..."|
|6||"RuneScape has been updated! Please reload this page."|
|7||"This world is full. Please use a different world."|
|8||"Unable to connect. Login server offline."|
|9||"Login limit exceeded. Too many connections from your address."|
|10||"Unable to connect. Bad session id."|
|11||"Login server rejected session. Please try again."|
|12||"You need a members account to login to this world. Please subscribe, or use a different world."|
|13||"Could not complete login. Please try using a different world."|
|14||"The server is being updated. Please wait 1 minute and try again."|
|15||See the notes below.|
|16||"Login attempts exceeded. Please wait 1 minute and try again."|
|17||"You are standing in a members-only area. To play on this world move to a free area first."|
|20||"Invalid loginserver requested. Please try using a different world."|
|21||"You have only just left another world. Your profile will be transferred in: (number) seconds."|
|None of the above||"Unexpected server response. Please try using a different world."|
Regarding response code 15
On the server, players are not unregistered for quite some time. This can be best witnessed when the client forcefully closes the connection while in combat. If you're quick enough before the player dies or kills the NPC, login attempts during that time return that the account is already logged in. This probably explains why the message says "try again in 60 seconds", and they just reused the response when the player is truly logged in.
Going along with this "players aren't offline yet" idea, when the client experiences some lag and performs a reconnect, it byte 18 as it's "connection type" to the server.
The server most likely saves this as a boolean (reconnect = var == 18;). When the login is entirely validated, meaning the password's are okay and the server isn't full, it can either send back the normal response, 2, or 15.
But why 15? If you look at the client code, you'll see that the chat messages aren't cleared. If you've ever had a shitty connection you've noticed that your chat stays there upon a reconnect, and this is exactly why. There are some minor annoyances with implementing response 15, since you can't send the rights byte (or the flagged byte, I forget which).
Stage 1: Client -> Server
Stage 2: Server -> Client
|long||"server session key"|
Stage 3: Client -> Server
|long||"client session key"|
|long||"server session key"|
Stage 4: Server -> Client
(needs to be documented)
Server -> Client Packets
|98||VARIABLE_BYTE||N/A||Send message||Sends a server message (e.g. 'Welcome to RuneScape') or trade/duel request.|
|99||VARIABLE_SHORT||N/A||Update players||Sends the player update block.|
|128||FIXED||0||Logout||Disconnects the client from the server.|
Client -> Server Packets