From f39c11847c9653e3dc47e32012182dfcfa107e49 Mon Sep 17 00:00:00 2001 From: Malloc of Kuzkycyziklistan Date: Tue, 16 May 2017 08:28:43 -0500 Subject: [PATCH] does this look good let's see --- protocol.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/protocol.md b/protocol.md index e918117..bbe021c 100644 --- a/protocol.md +++ b/protocol.md @@ -10,7 +10,7 @@ All references to the 'byte' in this document refers to individual 8-bit octets, Because the body of the packet is a sequence of many different regions of byte data that is not delimited, it is necessary for the header of the packet to determine boundaries for the regions of data. -* The first byte is the packet id, the necessary ones of which are defined in the _SERVER_ and _CLIENT_ sections. +* The first byte is the packet id, the necessary ones of which are defined in the _BODY_ section. * The second byte is the number of byte regions in the packet. * The bytes following the second byte are a list of binary length segments, each of which correspond to the number of bytes in its respective region. They each follow this format: * If length is less than 254, the length of the region is stored in a single byte. @@ -25,20 +25,30 @@ The message body immediately follows the header with no separator, and consists ### Numeric Packing -All numbers, unless otherwise specified here or in the packet ID section, are the string representation of a base 10 number. Common exceptions below: +All numbers, unless otherwise specified here or in the _BODY_ section, are the string representation of a base 10 number. Common exceptions below: * User IDs: 8 bytes, integer, unsigned * Co-ordinates: 8 bytes, double-precision float +### Packet IDs + +#### Server to Client + +0. login and registration login and registration login and registration login and registration login and registration login and registration login and registration login and registration login and registration login and registration login and registration login and registration + +#### Client to Server + + + ## Sockstamps Because epoch time is not standardized across systems, an intermediate layer of date/time transmission must be used between the client and server so as to handle time dependent interactions. Therefore, a "sockstamp" will be used in place of the context-dependent implementations of epoch time. A sockstamp is a sequence of six bytes that represent a fully qualified date and time. For the best use of space without obfuscating the data too much, the year's lower four bits and the four bits signifying the month are shared in the same byte, but no other components are joined. -The 12 bits signifying the year are an unsigned quanitity, and indicate the number of years since 1800; anything that happened before the year 1800 cannot be represented in this format, but this should never be necessary. The effective range of years that can be expressed by this format is 1800 AD to 5895 AD. +The 12 bits signifying the year are an unsigned quanitity, and indicate the number of years since 0 AD; anything that happened before the year 1 AD cannot be represented in this format, but this should never be necessary. The effective range of years that can be expressed by this format is 0 AD to 4095 AD. -The indexed list below indicates which byte (the first being byte 1) contains what information: +The indexed list below indicates which byte (the MSB being byte 1) contains what information: 1. Upper 8 bits of the year quantifier. 2. Upper 4 bits are the four least significant bits of the 12-bit year quantifier. The lower 4 bits are the month quantifier, ranging from 0 to 11. 3. Day of month quanitifier. Ranges from 0 to 30.