When writing a string from the server (linux) to the client (windows) the buffer is going to contain 4 random bytes in the end of the buffer.
The buffer contains a short (3 bytes) that write the length of the string which works fine. The string characters in themselves convert fine however 4 unset bytes are always set for some reason.

This bug occured in instances where SendError() was used on the backend, it happens regardless of what string is sent and where SendError() is called from.

This only happens when a string is sent from server to client. Client to server strings work fine.

Floats when written using htonl from the client (windows) and read using ntohl on the server (linux) will remove any decimals, interpreting a float as a int where 1.9 would become 1.
Floats when written using htonf from the client (windows) and read using ntohl on the server (linux) will be read as 0 regardless of conditions.

Current float values sent from client to server is temporarily written as strings and converted to floats on the server.

The version of the project that was handed in was made with a DirectX9 graphics backend which has proved to be challenging for creating and rendering textures from a byte stream.
This issue aims to address this as an issue that can be fixed by swapping out the backend with OpenGL or possibly rewriting the entire frontend on the OpenGL backend.

This issue aims to address the current lack of a video frame byte stream message implementation that allows the backend (drone application) to send video frames of any resolution preferably above 800x600 over the custom protocol (TCP transport).

This implementation should be tested with 1920x1080 resolution that is about 6 million bytes which would be an interesting test.