Programmierprojekt/documents/docs/networking/commands/protocol-document.md

Protocol Document

This document describes the protocol for client-server communication in our application. It defines the structure of requests and responses, the supported commands along with thier request parameters, response formats and possible errors.

Table of Contents

• Protocol Document
• Table of Contents
• General structure of requests
• Preconditions
  • Parsing
    • Error Response
  • Command dispatching
    • Error Response
  • Command parsing
    • Error Response
• Pre executions checks
  • UserLoggedInCheck
    • Error Response
• Commands
  • PING command
    • Required pre-execution checks
    • Request Parameters
    • Success Response
  • CHECK_USERNAME command
    • Required pre-execution checks
    • Request Parameters
    • Success Response
  • LOGIN comamnd
    • Required pre-execution checks
    • Request Parameters
    • Success Response
    • Error Response
  • LOGOUT command
    • Required pre-execution checks
    • Request Parameters
    • Success Response
    • Error Response

General structure of requests

As mentioned before, our protocol is based on POP3. Each command is represented as a single line of text, starting with the command name followed by parameters. The server responds with a status line indicating success or failure, followed by the body.

Requests can have parameters that provide additional information for the command. Parameters are key-value pairs separated by a equal sign (=).

Responses are collections of key-value pairs, containing either a value or another collection, allowing for nested structures. Each collection is ended with the END keyword.

Preconditions

The serverside pipeline to process incomming requests consists of multiple stages. Each of these stages can yield an error response if the request does not meet the requirements of that stage.

Parsing

One of these stages is the parsing. It is responsible for parsing the raw request into a structured format that can be easily processed by the command handlers. It validates the syntax of the request aswell.

Error Response

Code	Discription
PARSING_ERROR	The body of the request contains syntax errors (see message field of response for more details)

Command dispatching

After the request has been successfully parsed, the next stage is to dispatch the PrimitiveRequest to the appropriate CommandParser. This is done by the CommandDispatcherDispatcher, which uses the command name to determine which parser to use.

Error Response

Code	Discription
UNKNOWN_COMMAND	The command is unknown to this server. No parser has been defined

Command parsing

Once the PrimitiveRequest has been dispatched to the appropriate CommandParser, the parser is responsible for parsing the parameters of the request and creating a Request that can be executed by the responsible CommandHandler.

Error Response

Code	Discription
MISSING_PARAMETER	A required parameter is missing from the request (see message field of response for more details)

Pre executions checks

Pre-execution checks are reusable validation steps that can be registered on command handlers. They are implemented as HandlerCheck instances and are executed by the CommandHandlerExecutor before the handler's main logic is invoked.

UserLoggedInCheck

The UserLoggedInCheck is a common pre-execution check that verifies whether the user is logged in (i.e. has a user associated with his session).

Error Response

Code	Discription
USER_NOT_LOGGED_IN	The user is not logged in

Commands

Commands are the core of our protocol, representing the various actions that clients can request from the server. Each command has a unique name and may require specific parameters in addition to pre-execution checks. The server processes these commands and responds accordingly.

PING command

The PING command is a simple command that can be used to check if the server is responsive.

Required pre-execution checks

None.

Request Parameters

No parameters.

Success Response

No response fields.

CHECK_USERNAME command

The CHECK_USERNAME command is used to check if a username is already taken by another user. Additional users can still login with the same username, but thier name will be subsituted with a suffix.

Required pre-execution checks

None.

Request Parameters

Parameter Name	Type	Optional	Description
USERNAME	String	no	The username to check for availability

Success Response

Field	Type	Description
STATUS	Enum<UsernameAvailability>	Member of enum indicating if the username is available or already taken

Members of UsernameAvailability	Description
FREE	Username is available
TAKEN	Username is already in use

LOGIN comamnd

The LOGIN command is used to log in a user with a specified username. If the username is already taken by another user, the server will append a suffix to the username to make it unique.

Required pre-execution checks

None.

Request Parameters

Parameter Name	Type	Optional	Description
USERNAME	String	no	The username to create the user with

Success Response

Field	Type	Description
USERNAME	String	Username of the newly created user, can differ from the requested one
ID	UUID	The ID of the created user

Error Response

Code	Discription
ALREADY_LOGGED_IN	The session is already associated with a user, logging in again is prohibited.

LOGOUT command

Description of the command, what it does and when it should be used.

Required pre-execution checks

None.

Request Parameters

No parameters.

Success Response

No response fields.

Error Response

Code	Discription
NO_USER_ASSOCIATED	The session has no user associated, logging out is not possible.