- Habbo Development Wiki - Communication - Structure
FUSE makes use of a TCP/IP connection with each client to exchange messages, each one of them with an unique structure.
A message may or may not have a body. Different messages contain different body structures. The structures tend to be inconsistent between messages.
Requests (Client → Server)
The first 3 characters are in Base64 encoding, and they indicate the length of the rest of the request, not including this 3 characters in that length. This is used by the server to know the point where the request ends and the next one starts. If the request length is 2 (cooresponding to just the request ID length), it does not have a body, and if it is longer, it does.
The next 2 characters, also in Base64, contain the request ID. This allows to identify this specific request.
If this particular request does not have a body, this is the end of the request. However, if the request has a body, this is where it starts. A body contains a series of one or more parameters. Notice that this structure does not apply to all the requests, but to the majority of them.
A text parameter starts with a number in VL64 (2 characters) indicating the length of the following text to read.
A number parameter contains a number in VL64, whose encoding is explained below in the page.
As previously stated, some requests do not follow this, and use a different structure instead.
Example request: @@w@EYdA@A2@Uext/external_vars.txt
[Request start]
@@_ → 3 characters in Base64, a 31 in decimal; the rest of the request is 31 characters long.
@E → 2 characters in Base64, a 5 in decimal; this is the request with ID 5 (VERSIONCHECK).
[Body start]
YdA → Number in VL64 (401 in decimal); Y is an ASCII character in Base4, (2 in decimal); the next 2 ASCII characters are in Base64.
@A2 → String, @A is its length in Base64 (1 in decimal); the next character is the string itself.
@Uext/external_vars.txt → String, @U is its length in Base64 (21 in decimal); the next 21 characters are the string itself.
[Body end]
[Request end]
Responses (Server → Client)
The first 2 characters are in Base64 encoding, and they contain the response ID. This allows to identify this specific response.
If this particular response does not have a body, this is the end of the response. However, if the response contains parameters, this is where they start. Notice that this structure does not apply to all the responses, but to the majority of them.
ASCII char2 is used to indicate the end of a text parameter. Numbers are encoded in VL64 and they do not have char2 at the end.
The end of the response is indicated with ASCII char1.
Example response: @F9917[2][1]
[Response start]
@F → 2 characters in Base64, a 6 in decimal; this is the response with ID 6 (WALLETBALANCE).
[Parameter 1 start]
9917 → Text string.
[2] → ASCII char2, indicates the end of this parameter.
[Parameter 1 end]
[1] → ASCII char1, indicates the end of the response.
[Response end]
NOTE: Notice that [2] and [1] make reference to ASCII char2 and char1 respectively, but they aren't actually those characters, because they do not actually have a visual representation.