Skip to content

Protocol Format

Jump to bottom
ME1312 edited this page Apr 27, 2022 · 16 revisions

This page explains how the SubData Data Protocol formats data in layers to show how the formatted data gets from the network to a packet registered through the API. This may be useful to those who need to emulate such a connection in a different programming language.

Layer 1: The Stream

We start out with a raw data stream. From here, the first order of business is to decide where each packet begins and ends. The strategy here is to use control characters.

                                 Encrypted Data                      (Repeat This Process)
                                        |                                               | 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0x17 ...
                                                                                   |      
                                                                             End-of-Packet

There are currently several valid control characters:
0x00 Keep-Alive: This control character does literally nothing
0x10 Read Byte: Does not parse the following byte for a control character
0x11 0x?? Read Bytes: Does not parse the following 4𝓍 bytes for control characters
0x12 0x?? Read KB: Does not parse the following 4𝓍 kilobytes for control characters
0x13 0x?? Read MB: Does not parse the following 4𝓍 megabytes for control characters
0x14 0x?? Read GB: Does not parse the following 4𝓍 gigabytes for control characters
0x15 0x?? Read TB: Does not parse the following 4𝓍 terabytes for control characters
0x16 0x?? Read PB: Does not parse the following 4𝓍 petabytes for control characters
0x17 End of Packet: Signals the end of a packet
0x18 Read Reset: Invalidates any data before this (if possible) and resets

Layer 2: The Shell

This layer takes the Encrypted Data stream from the last layer as input. There isn't all that much to see here since the stream is just fed to the Cipher that is currently active for decryption. Since SubData could theoretically support a vast array of ciphers, we'll just skip this section.

Layer 3: The Packet

This layer takes the Decrypted Data stream from the last layer as input. The next thing that needs to be done here is to decide where to send this data.

 Packet ID                                  Packet Data                                   
   |                                             |                                        
[ 0x0000 ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To decide which packet handler gets the packet data, we start off with an unsigned 16-bit numeric Packet ID. Then, we'll send the Packet Data InputStream to the selected packet handler to handle the data.

Layer 4: The Message (Optional)

There is an additional layer for Messages. Messages are a bit more inefficient than packets, but because of their formatting they are ideal for Mods or Plugins. This layer uses Packet Data from the last layer as input. What has to be done here is splitting a single Packet ID into an infinite number of Message channels and handles.

   Channel                Handle                               Message Data               
      |                      |                                       |                    
[ "subdata" 0x1B 0x03 "examplepacket" 0x1B 0x03 ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             |    |                    |    |                                             
           End-of-Text               End-of-Text

Within the header there are two valid special characters:
0x1B Escape: Can escape itself or activate the functionality of the character below
0x03 End of Text: Represents the end of a string value

The Channel string is used to determine which pool of message handlers to select from. The Handle string is used to determine which message handler from that pool to select. Then, we'll send the Message Data InputStream to the selected message handler to handle the data.

Clone this wiki locally