30
edits
Changes
Jump to navigation
Jump to search
Created page with "RCD is a framework that manages '''r'''emote '''c'''ontrolled '''d'''evices - RC toys that connect to the Nintendo Switch via 802.11 ("WiFi") link. The first (and currently on..."
RCD is a framework that manages '''r'''emote '''c'''ontrolled '''d'''evices - RC toys that connect to the Nintendo Switch via 802.11 ("WiFi") link. The first (and currently only) released product to use this framework is [[Mario Kart Live: Home Circuit]].
RCD devices must be paired to the host Switch system in some way (e.g. QR code) and contain the connection settings in non-volatile memory so that they can reconnect on next use without needing to repeat the pairing process.
The RCD framework implements a very simple TCP-based RPC protocol that allows an RCD client to invoke methods on an RCD server. Note that multiple such connections may be established between the Switch and device.
= RCD RPC =
A client connects to a TCP server and sends as many commands as it likes, one at a time (and reading the response after each), before tearing down the TCP connection. It is not valid for a client to send a response to a server or for a server to send a request to a client.
Commands have a 0x10-byte header, followed by a payload of any size up to some maximum (typically 0x1000). All numbers are represented in big-endian format.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0 || 0x2 || Service being accessed
|-
| 0x2 || 0x2 || Command being invoked on that service
|-
| 0x4 || 0x4 || Payload length (PLEN)
|-
| 0x8 || 0x4 || Status code; ignored (and set to 0) for requests, an [[Error codes|error code]] for responses
|-
| 0xC || 0x1 || Flags; currently only the 1s bit is significant: it indicates a response
|-
| 0xD || 0x3 || Padding; zero.
|-
| 0x10 || PLEN || The parameters to the command, or the response
|}
In theory, multiple "services" could be multiplexed over a single TCP connection, but in practice only a single service is allowed per TCP port.
== Handshake protocol ==
Service ID: 0x0001
Commands: 4
When a device first establishes a wireless connection, it connects to the Switch on a well-known port to access the "handshake" service and make its presence known. A successful handshake causes application-specific RCD connections to be established. Commands must be sent in order (and no more than once).
RCD devices must be paired to the host Switch system in some way (e.g. QR code) and contain the connection settings in non-volatile memory so that they can reconnect on next use without needing to repeat the pairing process.
The RCD framework implements a very simple TCP-based RPC protocol that allows an RCD client to invoke methods on an RCD server. Note that multiple such connections may be established between the Switch and device.
= RCD RPC =
A client connects to a TCP server and sends as many commands as it likes, one at a time (and reading the response after each), before tearing down the TCP connection. It is not valid for a client to send a response to a server or for a server to send a request to a client.
Commands have a 0x10-byte header, followed by a payload of any size up to some maximum (typically 0x1000). All numbers are represented in big-endian format.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0 || 0x2 || Service being accessed
|-
| 0x2 || 0x2 || Command being invoked on that service
|-
| 0x4 || 0x4 || Payload length (PLEN)
|-
| 0x8 || 0x4 || Status code; ignored (and set to 0) for requests, an [[Error codes|error code]] for responses
|-
| 0xC || 0x1 || Flags; currently only the 1s bit is significant: it indicates a response
|-
| 0xD || 0x3 || Padding; zero.
|-
| 0x10 || PLEN || The parameters to the command, or the response
|}
In theory, multiple "services" could be multiplexed over a single TCP connection, but in practice only a single service is allowed per TCP port.
== Handshake protocol ==
Service ID: 0x0001
Commands: 4
When a device first establishes a wireless connection, it connects to the Switch on a well-known port to access the "handshake" service and make its presence known. A successful handshake causes application-specific RCD connections to be established. Commands must be sent in order (and no more than once).