Does the RoRNet protocol have documentation?

TheDude53

Skinning RoR into the future
Joined
Sep 4, 2020
Messages
13
Location
Eagan, MN
I'm toying with the idea of building a RoRNet protocol implementation for Node.js, however I can't find any documentation on the protocol itself. Have I simply missed something or does it not exist? I would read the code, but seeing as I am not proficient in C++ this would most likely be a waste of time.
 

only_a_ptr

Lead Developer
Administrator
Developer
Joined
Jan 31, 2018
Messages
34
Location
Prague, CZ
Hi. We have no doc, RoR codebase serves as reference implementation. We also have a Python interface: https://github.com/tritonas00/RoRServerBot/blob/master/RoRnet.py.

Anyway, If I should write docs for it, what structure should it have? I'll try to create an outline here:
UPDATE: server part

Hope this helps.
 
Last edited:

only_a_ptr

Lead Developer
Administrator
Developer
Joined
Jan 31, 2018
Messages
34
Location
Prague, CZ
I've been working on the rorserver for past ~2 weeks and I realized some scenarios are not defined very well. For example: should the server expect the client to close the socket connection, or should it actively close it? Right now both sides race to do it, but coincidentally the server is slower - which is good, otherwise the client would show an "error" box on every regular disconnect.

So, I'm going to start describing the known mechanics here and call it a draft documentation.

Overview of RoRnet 2.x protocol

RoRnet is a network protocol which enables Rigs of Rods simulator to be played by multiple clients over local network or the internet. It's a client-server protocol, where the server defines gameplay parameters (such as terrain name) and keeps track of connected clients and their vehicles.

The protocol provides these features:
  • Message exchange: getting server/client info, negotiating connections and spawning content.
  • Data streams: For dynamically changing data such as character/vehicle positions. New types can be added as needed.
  • User authentication via tokens.
  • User authorization via config files (permissions/blacklist).
  • Serverlist integration via REST API, see reference implementation at https://github.com/RigsOfRods/multiplayer.rigsofrods.org.
A reference server implementation is at https://github.com/RigsOfRods/ror-server. For instructions to build and run, visit https://docs.rigsofrods.org/gameplay/multiplayer-server-setup/.

For breakdown of the codebase, see https://forum.rigsofrods.org/threads/does-the-rornet-protocol-have-documentation.3168/#post-15086

Server startup

Upon startup the server creates a HTTP socket, `bind()`s it to configured IP address & port and `listen()`s for incoming connections.

Client connection

Clients creates a HTTP socket and `connect()`s to server's IP/port. If the connection is successful, client starts sending sequence of messages:
  1. HELLO with RoRnet version string as payload. If sending fails, client immediatelly `disconnect()`s the socket. If client sends anything else than HELLO, server immediately `disconnect()`s the socket. If the version is not supported, server replies WRONG_VER and `disconnect()`s the socket (so does client after receiving). If the version is OK, server replies HELLO with `RoRnet::ServerInfo` as payload. On any other response, client disconnect()s.
  2. USER_INFO with `RoRnet::UserInfo` as payload. Client error sending -> disconnect(). Server error receiving -> disconnect(). If server uses password and login fails -> server replies WRONG_PW and disconnect()s. If the user is banned, server replies BANNED but doesn't disconnect() [?!]. If the server is full, it replies FULL and disconnect()s. Otherwise server replies WELCOME with assigned client ID and verified `RoRnet::UserInfo` as payload (username may be updated to remain unique).
Next, server broadcasts USER_JOIN to all clients (including the one just connected) with `RoRnet::UserInfo` as payload (auth token and GUID are blanked).

Client registering stream

Streams may fulfill any purpose - the server doesn't recognize and control their content, only broadcasts the data to other clients.

TO BE CONTINUED...
 
Top