Racinfo

Real Address Chat Protocol

As mentioned earlier, RAC is a TCP-based protocol, so the server and client communicate by sending TCP packets to each other. The implementation is pretty simple, so don’t worry.

All RAC servers use port 42666 by default, but servers that implement RACS (Real Address Chat Secure) use port 42667.

Keep in mind that the RAC server closes the connection after each message sent from the client. In some cases, it might receive two packets, but it will still close the connection.

Receiving messages

Receiving messages from the server is implemented in an unusual way. There are two ways to receive messages from the server.

But before you try to receive new messages, you need to get the total size of all messages. The messages are stored on the server in a single file, and to get new messages, you should send an offset.

To receive the current size of the messages on the server, you need to send a 0x00 byte to the server. In response, the server will return the current size of the messages. Now, let’s begin receiving those messages.

The first way is to receive all messages stored on the server. The client should send a 0x00 byte and then, in the same stream, send a 0x01 byte to the server. The server will respond with all messages, separated by \n.

The second way is to get messages in chunks. Again, the client sends a 0x00 byte and then sends a 0x02 byte, along with the size of the messages it wants to receive. The number of messages to receive is calculated using this formula:

The server will send messages matching the requested size, separated by \n.

Sending messages

Sending messages in RAC is implemented simply, but with some interesting details. The server doesn’t identify clients or users, so clients have to handle that themselves. This means the client must send the user agent, username, and message all in one packet. For example:

Did you notice the ▲ symbol? This is called a User Agent. In this example, the message was sent by the Tower client, because ▲ is its respective user agent. As mentioned earlier, the server itself cannot identify clients, so clients have to identify each other using these user agents.

Also, note that zero is wrapped inside <>. This approach makes parsing messages easier with regex. Learn more about user agents and how to create your own in the user agents article.

Note that the server should store the IP address with each sent message. However, messages sent by clients in authorized mode should be ignored for this. This idea, introduced by Sugoma, means that clients shouldn’t be anonymous unless they’re authorized. Still, most clients ignore the IP address and don’t display it.

Back to sending messages: To send a message to the server, the client should send a 0x01 byte, followed by the message in the same packet—not separately. After that, you won’t receive anything from the server, even if there’s an error. So your final message should look like this:

Also, server that are implements RAC v2 allows to send messages in authorized mode. To send message in authorized mode, you need to send 0x02 and after that, separating by \n, send user's user name, password and message (do not include \n in the end).

If the message was sent successfully, the server won’t send any response. If not, the server will send a 0x01 byte if the user doesn’t exist, and a 0x02 byte if the password is incorrect.

Authorization

Authorization is only available on servers that implement the RAC v2 protocol, which adds an authorization system. This feature was added by Sugoma for people who don’t want to expose their IP address to everyone.

Before sending messages in authorized mode, you need to register a user on the server. To do this, the client should send a 0x03 byte and, just like when sending messages, include the username and password separated by \n. If the user is created, the client will receive nothing in response. If the user already exists, the server will respond with a 0x01 byte.

TLS Connection

You can wrap your connection with TLS encryption. There’s nothing special about it.

Special Packets

Some servers can implement special packets, but most of the time they don’t add much functionality.

One of them is the 0x69 byte. You can send this byte to the server to get technical information about it. For example, after sending this byte, you might receive these bytes in response:

Also, right after this byte, the server will send information about itself, such as the server software name and its version.