Update MediaWiki page '317 Protocol'

This commit is contained in:
Ramen 2011-06-19 05:42:51 +00:00 committed by moparisthebest
parent c32755844d
commit 1615586ce9

View File

@ -5,7 +5,7 @@
== '''Packet structure''' == == '''Packet structure''' ==
When the client sends a packet to the server, the first byte encapsulates its opcode. This specific opcode is encrypted with a value generated by the ISAAC PRNG seeded with a dynamically server generated key during the login block. The server decrypts it and associates the opcode to the packet's respective predefined size. If the packet does not contain a fixed size, the opcode will be followed by either a byte or a word - varying per packet - for its proper size. This is then followed by the payload. When the client sends a packet to the server, the first byte encapsulates its opcode. This specific opcode is encrypted with a value generated by the ISAAC PRNG seeded with a dynamically server generated key during the login block. The server decrypts it and associates the opcode to the packet's respective predefined size. If the packet does not contain a fixed size, the opcode will be followed by either a byte or a word - varying per packet - for its proper size. This is then followed by the payload.
== '''Login''' == <math>Insert formula here</math>== '''Login''' ==
Every connection to the main 'gateway' server sends a single byte of data, mostly well known as the connection type. The connection type tells the main server which type of connection you wish to initiate. The old engine list consists of: Every connection to the main 'gateway' server sends a single byte of data, mostly well known as the connection type. The connection type tells the main server which type of connection you wish to initiate. The old engine list consists of:
* Login request - connection type 14 * Login request - connection type 14
* Update - connection type 15 * Update - connection type 15
@ -14,15 +14,13 @@ Every connection to the main 'gateway' server sends a single byte of data, mostl
The connection type we will cover in the following paragraphs is the login connection type, 14. After the login handshake initiating connection type, the client writes a small bit of data derived from the logging in player's username. This is believed to help select the appropriate login server. On successful handshake, the server sends back 8 ignored bytes. The connection type we will cover in the following paragraphs is the login connection type, 14. After the login handshake initiating connection type, the client writes a small bit of data derived from the logging in player's username. This is believed to help select the appropriate login server. On successful handshake, the server sends back 8 ignored bytes.
<code> <pre>long l = TextUtils.encodeAsBase37Integer(username);
long l = TextUtils.encodeAsBase37Integer(username);
int i = (int) (l >> 16 & 31L); int i = (int) (l >> 16 & 31L);
out.offset = 0; out.offset = 0;
out.writeByte(14); // Initiate connection type out.writeByte(14); // Initiate connection type
out.writeByte(i); // "small bit of data derived from... player's username" out.writeByte(i); // "small bit of data derived from... player's username"
in.queueBytes(2, out.payload); in.queueBytes(2, out.payload);
for (int j = 0; j < 8; j++) in.read(); for (int j = 0; j < 8; j++) in.read();</pre>
</code>
At this point, the client reads in one byte, called the status code. The status code 0 is expected to start the login protocol correctly. If the status code is 0, the client reads a long, dubbed by many as the server session key. This is used to help generate a unique seed for the client session's packet opcode masking. The client then stores two ints that are the upper and lower ints of the client session key, which has the same purpose as the server's key. The client then starts writing the login block, which is RSA encrypted. At this point, the client reads in one byte, called the status code. The status code 0 is expected to start the login protocol correctly. If the status code is 0, the client reads a long, dubbed by many as the server session key. This is used to help generate a unique seed for the client session's packet opcode masking. The client then stores two ints that are the upper and lower ints of the client session key, which has the same purpose as the server's key. The client then starts writing the login block, which is RSA encrypted.