Difference between revisions of "Core Protocol"

Latest revision as of 12:59, 16 February 2015

This protocol is UDP and bi-directional. It can be thought of as another layer within an application's network layer. Subgame, ASSS, Continuum, VIE's SubSpace client, the Directory server, and some Billing Servers utilize this protocol.

There is support for reliable ordered packets, large packets and cluster packets.

• The maximum packet size is 520 bytes
• All integers are little endian
• All core packets begin with the type byte 0x00
• Packets can be nested (They are usually processed recursively)

0x01 login
offset size comment
0      1    type 0x00
1      1    type 0x01
2      4    client key
6      2    protocol version (vie = 0x01, ctm = 0x11)

0x02 login response
offset size comment
0      1    type 0x00
1      1    type 0x02
2      4    ~client key (negative)

0x03 reliable header (see reliable packet addendum below)
offset size comment
0      1    type 0x00
1      1    type 0x03
2      4    packet id (ie: ACK_ID)
6      ?    payload (514 bytes max)

0x04 reliable acknowledge (see reliable packet addendum below)
offset size comment
0      1    type 0x00
1      1    type 0x04
2      4    packet id (ie: ACK_ID)

0x05 sync
offset size comment
0      1    type 0x00
1      1    type 0x05
2      4    local time
6      4    packets sent
10     4    packets received

0x06 sync response
offset size comment
0      1    type 0x00
1      1    type 0x06
2      4    time from last received 0x05 packet
6      4    server time

0x07 disconnect
offset size comment
0      1    type 0x00
1      1    type 0x07

0x08 small chunk
offset size comment
0      1    type 0x00
1      1    type 0x08
2      ?    payload (expect 472 max)
keep appending payloads until 0x09 chunk tail is received

0x09 chunk tail
offset size comment
0      1    type 0x00
1      1    type 0x09
2      ?    payload (expect 472 or less)
append this payload then process contents as a non-core packet

0x0A stream
offset size comment
0      1    type 0x00
1      1    type 0x0A
2      4    total length of all segments
6      ?    payload 
keep appending payloads until total length is reached then process contents as
a non-core packet.

0x0B cancel stream request
offset size comment
0      1    type 0x00
1      1    type 0x0B

0x0C cancel stream acknowledge
offset size comment
0      1    type 0x00
1      1    type 0x0C

0x0E cluster
offset size comment
0      1    type 0x00
1      1    type 0x0E
2      1    length
3      ?    payload with length as above
packet repeats from offset 2 until end, process contents as arbitrary packet

0x10 Continuum alternate encryption response (s2c)?
offset size comment
0      1    type 0x00
1      1    type 0x10
2      10   ??

0x11 Continuum alternate encryption response response (c2s)?
offset size comment
0      1    type 0x00
1      1    type 0x11
2      6   ??

Reliable Packet Handling Addendum

Here are some tips when implementing a reliable packet handler stack.

For outgoing traffic:

     1. All outgoing traffic must be put into a send list until an ACKnowledgement (0x04) is received with
             the same ACK_ID as the traffic.
     2. Sometimes double-sending reliable messages is warranted, given high-bandwidth and high-packetloss.
     3. ACK's (0x04) should cause disconnection if you have not sent a message with that ACK_ID yet.
     4. ACK_ID starts at 0 for both client and server, ACK_ID is incremented by one every time.

For incoming traffic:

     1. ACK (0x04) all incoming Reliable traffic no matter what.  ACK the traffic twice if it makes you feel happy.
     2. All incoming traffic must be processed in the order of the ACK_ID's.
     3. If a packet is lost, all traffic stamped with an ACK_ID higher than the next expected ACK_ID
             must be placed on a backlog list of packets until the packet in sequence is finally received.
     4. If an incoming reliable message's ACK_ID has already been processed, ignore the packet.

External Links

• Catid's Subspace Addendum