University-of-Basel-Studentprojects/Programmierprojekt
Archived
1
0
Fork 0
Code Issues 17 Pull Requests Actions Wiki Activity

Merge branch 'main' into feat/game-ui

Browse Source 
# Conflicts:
#	src/main/java/ch/unibas/dmi/dbis/cs108/casono/client/network/GameClient.java
#	src/main/java/ch/unibas/dmi/dbis/cs108/casono/client/ui/gameui/CasinoGameUI.java
#	src/main/resources/ui-structure/Casinogameui.fxml
This commit is contained in:
Julian Kropff
2026-04-11 15:16:46 +02:00
parent 2e705185f4 f54182fde6
commit 30dcd8f4ab
44 changed files with 1659 additions and 793 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documents/docs/networking/Network-Protocol-Documentation.md
-63
View File
@@ -1,63 +0,0 @@
This Document states the Network-Protocol as it is currently implemented
## GET_MESSAGE_COUNT
This Command gets the number of messages, currently stored in the queue for the specific client.
(Is used together with GET_NEXT_MESSAGE, to get all messages that are currently in the queue)
Example:
```
GET_MESSAGE_COUNT
1
+OK
```
## GET_NEXT_MESSAGE
This Command gets the next Message that is being stored in the queue for the client.
(Command is being sent the amount of times, the GET_MESSAGE_COUNT Command returns)
Example:
```
GET_NEXT_MESSAGE
TYPE=LOBBY GAME=1 USER=player1 TARGET=null TIME=9:30 TEXT="Guten Tag"
+OK
```
## SEND_MESSAGE
This Command gets sent if the user of that client writes a message to one of the three possible chats
(The Arguments / Parameters of the Command describe all the parameters of the Object "Message" being used internally by both the Client and the Server)
Example:
```
SEND_MESSAGE TYPE=LOBBY GAME=1 USER=player1 TARGET=null TIME=10:30 TEXT="Hallo Welt"
+OK
```
## LOG_IN
This Command is used to create a user on the server and associate that user with a username
Server returns the username, slightly changed if it is already used by someone else, and an ID to identify the client.
Example:
```
LOG_IN USERNAME="Peter"
USERNAME="Peter" ID=<random UUID>
+OK
```
## LOG_OUT
This Command is used to quit the connection between client and server.
Example:
```
LOG_OUT
+OK
```
documents/docs/networking/commands/protocol-document.md
+112
View File
@@ -341,4 +341,116 @@ LIST_USERS
END
END
END
```
## SEND_MESSAGE command
The `SEND_MESSAGE` command is used to transfer the chat message sent by a user to the server.
### Required pre-execution checks
None.
### Request Parameters
| Field | Type | Description |
|:---------|:----------------|:-------------------------------------------------------------------|
| `TYPE` | `Enum<ChatType` | Member of Enum, indicating with chat type is used |
| `GAME` | `int` | ID for identifying the Lobby Chat |
| `USER` | `String` | Username of the player that sent the message |
| `TARGET` | `String` | Username of to which the message is sent to (only in Whisper Chat) |
| `TIME` | `String` | Timestamp, when the message was sent |
| `TEXT` | `String` | Content of the message |
| Members of `ChatType` | Description |
|:----------------------|:--------------------------------|
| `GLOBAL` | Message is for the global chat |
| `LOBBY` | Message is for the lobby chat |
| `WHISPER` | Message is for the whisper chat |
### Success Response
No response fields.
### Error Response
None.
### Example Request
```
SEND_MESSAGE TYPE=GLOBAL GAME=1 USER=player1 TARGET=null TIME='10:30' TEXT='Hello World'
```
### Example Response
```
+OK
END
```
## GET_MESSAGE_COUNT command
The `GET_MESSAGE_COUNT` is used to get the current number of messages that are stored in the queue for a client.
### Required pre-execution checks
None.
### Request Parameters
No parameters.
### Success Response
| Field | Type | Description |
|:--------|:------|:-------------------------------|
| `COUNT` | `int` | The current number of messages |
### Error Response
| Code | Description |
| :------------------- |:---------------------------------------------------------------------------------|
| `NO_USER_ASSOCIATED` | The session has no user associated, there is no queue of messages for the client |
### Example Request
```
GET_MESSAGE_COUNT
```
### Example Response
```
+OK
COUNT=10
END
```
## GET_NEXT_MESSAGE command
The `GET_NEXT_MESSAGE` command is used to get the next message stored in a queue for the client.
### Required pre-execution checks
None.
### Request Parameters
No parameters.
### Success Response
| Field | Type | Description |
|:---------|:----------------|:-------------------------------------------------------------------|
| `TYPE` | `Enum<ChatType` | Member of Enum, indicating with chat type is used |
| `GAME` | `int` | ID for identifying the Lobby Chat |
| `USER` | `String` | Username of the player that sent the message |
| `TARGET` | `String` | Username of to which the message is sent to (only in Whisper Chat) |
| `TIME` | `String` | Timestamp, when the message was sent |
| `TEXT` | `String` | Content of the message |
| Members of `ChatType` | Description |
|:----------------------|:--------------------------------|
| `GLOBAL` | Message is for the global chat |
| `LOBBY` | Message is for the lobby chat |
| `WHISPER` | Message is for the whisper chat |
### Error Response
| Code | Description |
| :------------------- |:---------------------------------------------------------------------------------|
| `NO_USER_ASSOCIATED` | The session has no user associated, there is no queue of messages for the client |
### Example Request
```
GET_NEXT_MESSAGE
```
### Example Response
```
+OK
TYPE=GLOBAL GAME=-1 USER=player1 TARGET=null TIME=9:30 TEXT="Guten Tag"
END
```
documents/docs/our-protocol.md
+72
View File
@@ -0,0 +1,72 @@
# Our Network Protocol Documentation
## Overview
Our protocol is inspired by *POP3*, but has been highly customized to fit our specific needs.
It is a text-based protocol operating over raw TCP sockets, designed for human readability and strict structure.
## Packet Structure
Each network packet consists of:
- **4-byte header**: Specifies the size of the payload (big-endian integer).
- **4-byte request ID**: Generated by the client, used to match requests and responses.
- **Payload**: The actual data, its size as specified by the header.
This structure is used for both requests and responses.
## Conventions
- All keys (in both requests and responses) use UPPER_SNAKE_CASE.
- Only a-z, A-Z, 0-9 are allowed in keys.
- Only human-readable strings are transmitted.
- Binary data is not allowed.
## Request Format
A request consists of a single line:
```
COMMAND KEY1=ARG1 KEY2=ARG2
```
- **COMMAND**: The action to perform.
- **KEY=VALUE pairs**: Optional parameters. There may be zero or more.
- **Whitespace**: Extra spaces between key, separator, and value are ignored. Any other characters between them are an error.
- **Standalone values**: Not allowed. Every value must have a key.
### String Values
- Strings with spaces must be enclosed in single quotes: `'example string'`.
- Inside quoted strings, line breaks are allowed.
- To include a single quote inside a string, escape it (e.g., `'It\'s fine'`).
If these rules are violated, the request is considered invalid and will be rejected.
## Response Format
Responses are more complex and can represent nested collections.
- **Success**: Starts with `+OK`
- **Error**: Starts with `-ERR`
- After the status, a newline follows, then fields in the format `KEY=VALUE`.
- Collections and elements are ended with the `END` keyword.
- A collection starts with a key, and its elements are indented.
- A element starts with a key, and its fields are indented.
### Example: Nested Collection
```
+OK
KEY1=VALUE1
FIELDS
FIELD
NESTED_KEY=NESTED_VALUE
END
END
KEY2=VALUE2
END
```
## Error Handling
Any violation of the format (invalid characters, unescaped quotes, binary data, etc.) results in the request being rejected with an error response.
### Example Error Response When Violating Syntax Rules:
```
-ERR
CODE=PARSING_ERROR
MSG='Error occured during parsing. Likely due to malformed payload.'
END
```