protocol.txt

Epitech                                                Nicolas Lattemann
Request for Comments: 9999                                  Léon Sautour
Category: Networking                                     Sebastian Klemm
                                                          Pablo Herrmann
                                                          Epitech Berlin


                      R-TYPE COMMUNICATION PROTOCOL

Abstract

   This document provides an in depth specification of the client <->
   server communication protocol implemented during the Epitech R-Type
   project. The protocol as described in this document contains all
   necessary commands a client must implement in order to participate
   in games run by the R-Type server.

Status of this Memo

   This memo is the specification of the Communication Protocol
   implemented by its authors for the R-Type Epitech project. This
   specification is an exercise in the writing of an rfc document as
   defined by RFC 7322 "RFC Style Guide". This specification does not
   aim to be submitted at any point in time.

Copyright Notice

   This document is not subject to any copyright notice and thus
   expresses no rights reserved.

Table of Contents

    1. Introduction ...................................................X
    2. TCP Protocol ...................................................X
        2.1. Command Syntax ...........................................X
        2.2. Command Response .........................................X
            2.2.1. Response Codes and Meaning .........................X
            2.2.2. Specific Responses .................................X
        2.3. Server Commands ..........................................X
        2.4. Client Commands ..........................................X
    3. UDP Protocol ...................................................X
        3.1. Command Pieces ...........................................X
        3.2. Server Commands ..........................................X
            3.2.1. Server Command Listing .............................X
            3.2.2. Server Command Arguments ...........................X
        3.3. Client Commands ..........................................X
            3.3.1. Client Command Listing .............................X
            3.3.2. Client Command Arguments ...........................X
        3.4. Command Identifiers ......................................X

1. Introduction

    The R-Type project is an epitech project that aims to produce a
    multiplayer game based on the R-Type game.

    This project aims to introduce students to the intricate details of
    building a networked multiplayer game while also focusing on the
    package the game is delivered in. This includes but is not limited
    to :
    
        - Crossplatform build system
        - Limited user setup required
        - Multithreaded server
        - Inability to cheat using modified client

2. TCP Protocol

    The TCP protocol will serve as the main protocol used by the client
    and server before the start of a game. It will also serve the
    purpose of handling anything non relevent to the game currently
    being played. The sole exception to that last bit will be the
    handling of in game messaging and server message broadcasting.

    2.1. Command Syntax

        TCP commands follow the following syntax :

                <CMD> <SP> <HEADER>;<ARGS> <CRLF>

        Here is a definition of each part :

        <CMD>    -> This is the command name and will always be fully
                    capitalized.

        <SP>     -> Ascii space character

        <HEADER> -> For client commands, user UUID. For server commands,
                    server UUID. Both distributed by server on
                    connection.
        
        <ARGS>   -> Arguments for given command. These args are
                    separated by the ',' ascii character.

        <CRLF>   -> Carriage Return Line Feed character. Every message
                    will end in this character combination denoted
                    '\r\n' in ascii.

    2.2. Command Response

        All client sent commands will generate a response from the
        server allowing the client to know the status of their command.

        Responses will follow the following syntax :

                <CODE> <SP> <HEADER> <SP> <BODY> <CRLF>

        In this format, the HEADER is the server's UUID, that the client
        can use in order to make sure he is interacting with the correct
        server.

        The response format is similar to the command synthaxe, except
        that the cmd is replaced by a three digit response code that
        mimics that of the HTTP protocol.
    
        2.2.1. Response Codes and Meanings

            The following is a list of all possible response code. This
            list of response codes is strongly inspired by the response
            codes of the HTTP protocol.

                - 500 -> Wrong Request
                - 401 -> Forbidden
                - 200 -> OK

        2.2.2. Specific Responses

        Sub args are comma separated and args are semi colom separated.

        GET_LOBBIES Response:

            code: 200
            body: (lobby id, playerCount, isRunning);

    2.3. Server Commands

        The only server command that currently needs any handling by the
        client is the START command.

        The START command will provide one argument, which is the port
        that the client should send his first UDP message to.
    
    2.4. Client Commands

        The following is a list of Client Commands :

            - AUTHENTICATE     -> Only command with no header. This command
                          allows the client to retrieve his user
                          assigned uuid.

            - START       -> This command allows the user to signal
                          to the server that the game should start.

            - JOIN_LOBBY  -> This command allows the user to enter into
                            a given lobby.
            
            - GET_LOBBIES -> This command requests all lobbies available

            - LEAVE       -> Leave current lobby if in one.


3. UDP Protocol

    The UDP protocol will be the main protocol used to communicated the
    behaviour of the game to clients during any given game.
    
    Since in this project the server is supposed to handle most of the
    game logic this protocol will be centered around the ECS and
    communicating it's state over the course of a given game.

    NO UDP SERVER COMMAND will await any type of response.

    This protocol is a binary protocol for optimization purposes. This
    means that each command is refered to by it's unique identifier
    contained in the first byte of every packet. You may find the
    identifiers specified in section 3.4.

    ATTENTION: All udp packets must be prefaced by the size of the
               packet. This information is to be encoded in 2 Bytes
               and is of type unsigned short.

    3.1. Command Pieces

        The following is a listing of every different piece that can be
        used in a protocol command along with the steps / sizes needed
        in order to understand how to serialize and deserialize them.

        - entId:

            Size: 8 Bytes
            Type: Long long

        - componentId:

            Size: 4 Bytes
            Type: Int

        - songId:

            Size: 1 Byte
            Type: Unsigned char

        - compCount:

            Size: 1 Byte
            Type: Unsigned char

        - component:

            Size: variable
            
            The component piece is constituted of the following parts:

            - componentId
                Size: 2 Bytes
                Type: Unsigned char

            - componentSize (in bytes)
                Size: 8 Bytes
                Type: Unsigned long
                Note: Describes the size of the componentData

            - componentData
                Size: componentSize
                Note: Actual component data

        - direction:

            Size: 1 Byte
            Type: Unsigned char

        - uuid
            <TO BE SPECIFIED>
        
    3.2. Server Commands

        This section details the commands sent by the server to clients
        along with their usage.

        3.2.1 Server Command Listing

            The following is a listing of all valid server commands :

                    ENTITY           ->    Provide entity description,
                                           with component args.
                    DELETE ENTITY    ->    Delete entity
                    DELETE COMPONENT ->    Delete component
                    MUSIC            ->    Change Song
                    GAME END         ->    Signals end of game
                    DEATH            ->    Signals player is dead

        3.2.2. Server Command Arguments

            The following is an description of the pieces constituting
            the different server commands. Each piece is contained
            between parenthesis. If a piece is followed by '...', the
            command has a variable number of that given piece.

            ENTITY:
                (entId) (compCount) (component...)

            DEL_ENT:
                (entId)

            DEL_COMP:
                (entId) (componentId)

            MUSIC:
                (songId)

    3.3. Client Commands

        This section details the commands sent by the client to the
        server along with their arguments and usage.

        In contrast with Server Commands, some of these commands will
        elicit a response. However this response should not be awaited
        as it will come under the form of a normal server command.

        3.3.1. Client Command Listing

                HERE         ->      Signal connection to server
                GET ENTITY   ->      Get specification for entity
                ACTION SHOOT ->      Signal the server that the client
                                     shot.
                ACTION MOVE  ->      Signal the server that the client
                                     has moved.
                PING         ->      Signal server that client is
                                     still connected. Required every
                                     three seconds.

        3.3.2. Client Command Arguments

            The following is an description of the pieces constituting
            the different server commands. Each piece is contained
            between parenthesis. If a piece is followed by '...', the
            command has a variable number of that given piece.

            GET_ENT:
                (entId)

            ACT_SHOOT:
                No arguments

            ACT_MOVE:
                (direction)
            
            HERE:
                (uuid)

    3.4. Command Identifiers

        This section details the unique identifiers for each command.

        Server Commands

                ENTITY: 1
                DEL ENTITY: 2
                DEL COMPONENT: 3
                MUSIC: 4
                GAME END: 5
                DEATH: 6

        Client Commands

                HERE: 7
                GET ENTITY: 8
                ACTION SHOOT: 9
                ACTION MOVE: 10
                PING: 11