Issue

Currently for the server to get upstream changes for the dashboard they have to be compiled into a new server release. This solution works well for ensuring the server always has access to a dashboard regardless of internet connection however this means new releases have to be made every time the dashboard changes.

Proposed Solution

Leave the current solution as-is where the dashboard is compiled into the server but also extend this functionality to at server startup to request the dashboard GitHub to see if there is a new dashboard version released (Include associated information in the releases so that the server can determine whether its compatible with the new dashboard version) and if everything is compatible the server could download the new dashboard and save it in the server data folder to serve to clients instead

Checklist

• Dashboard releases are created and downloading them programmatically is implemented
• Server can determine compatibility with the dashboard versions
• Server can download a new dashboard version
• Server will serve locally stored dashboard files from the data folder if they are present

Description

Upgrading the axum and hyper dependencies for the new hyper v1 release.

Checklist

• Axum is upgraded to v0.7
• Hyper is upgrade to v1

Blocked by

The following issues must be resolved before this task can be completed:

• seanmonstar/reqwest#2039

Description

See if its possible to use the Discord game sdk to implement an invite system independently of the origin/ea overlay, this would improve the invite system reliability as the current reliability of the existing overlay is flakey and its unknown how long it will continue to work.

If this experiment is a success #32 can be closed

Checklist

• Game invites are integrated with discord
• Players can join each other through discord

Description

For larger servers being able to register an account through the dashboard might not be something that is ideal as users may spam create accounts to fill up the database or reserve names

Proposed Solution

Adding a disable account registration configuration setting to the server configuration.

Checklist

• Account registration can be disabled
• Server create account endpoint responds with an error when registration is disabled
• Disabled account registration is visible on the dashboard

Description

This is the tracking issue for the new server tunneling solution, this new layout will help make the WAN connectivity for Pocket Relay more reliable by using the server as a relay for the game client traffic.

In the standard game the client networking is a peer-to-peer structure where one client acts a host (server) and all the other clients connect to that client sending their information there which the host then provides the required details to the other clients.

This new solution takes advantage of being able to change the game networking topology from "PeerHosted" to "Dedicated" using this when a player creates a game as far as their game client is aware they have become a server for clients to connect too, but any other clients who join the game will be told instead that the game is a dedicated server and that they should connect to a local port (42132) this local port is apart of a pool of ports that the game server can use to talk to the client.

When the other clients then try to talk to 42132 on localhost the client takes all of the messages and forwards them to the Pocket Relay server which then sends them to the appropriate host players computer which then uses a local socket from a pool of sockets to send that data to the host "server" allowing the server and clients to communicate just as if they were all running on the same computer, thus bypassing any NAT restrictions that would normally cause issues.

The local pool of sockets is used to identify where each message is supposed to be sent, the server keeps track of which slot the player is in within the game and maps each player to one of the locally spawned sockets.

Diagrams

Below are some diagrams showcasing the different approaches

Checklist

• Experimental test demo
  • This was tested over LAN with two different devices and work correctly as expected
• Needs to be optional but enabled by default
  • New configuration variable must be added for this system to allow the server to disable it
• Proper stable implementation
  • The current implementation is very thrown together and needs to be stable/cleaned up before its distributed
• Testing for players who've had issues playing over WAN before

In my own blaze emulator i am using this to calculate the game protocol version hash, here you can see it in C#. It appears to be FNV1 hash but in a bit different way. When i tested this against EA generated hashes, they were matching.

I am not familiar with Rust at all, so it is better i let it up to you to implement it :D

        public static ulong GetGameProtocolVersionHash(string protocolVersion)
        {
            protocolVersion ??= string.Empty;
            //FNV1 HASH - the same hashing logic is used in ea blaze for game protocol versions
            byte[] buf = Encoding.UTF8.GetBytes(protocolVersion);
            ulong hash = 2166136261UL;
            foreach (byte c in buf)
                hash = (hash * 16777619) ^ c;
            return hash;
        }

Is your feature request related to a problem? Please describe.

Currently PocketRelay server listens on 0.0.0.0 (wildcard IP).

Describe the solution you'd like

It would be nice to be able to bind it to a specific IP address. Therefore, I propose adding ip (or host) option in config.json file in addition to the port which is already present.

Describe alternatives you've considered

N/A

Additional context

Security hardening.

Description

This change will persist leaderboard rankings and values in the database using the values provided through the GameReporting->SubmitOfflineGameReport (0x001c->0x0002) packets

This will prevent the need for the costly computation required to compute the leaderboard whenever it expires

Checklist

• Game report data is extracted
• Leaderboard database structures
• Leaderboard updated from game reports

Description

Currently the configuration is less flex-able as it is only loaded at server startup, the current configuration is also hard for docker users to modify. In order to create new features that can be toggled from the dashboard this proposal is to create a "runtime modifiable" configuration. This would allow the configuration to be modified by the dashboard

Checklist

• Configuration is implementation is altered so that its safely modifiable at runtime (RwLocks)
• Endpoints are created for setting the values of config variables
• Modified config variables are persisted to the config file

Description

Currently the server GitHub repository contains the sources for the Dashboard in the repository (Requiring these changes to be committed) this was previously required when crates.io was supported but due to #40 this has changed so these sources can now be excluded from the repository

Dependent

• Requires #40

Checklist

• Dashboard sources are excluded from the repository

Description

With EAs ever changing launcher it might become impossible to invite players to play together, it might be time to start investigating an external solution

Possible Solutions

Implementing an invite system into the client/launcher(future launcher) to allow searching for games/players and joining within the client tool outside of the game

Current Status

Not yet investigated

Description

Due to there being a fairly decent chance that QoS servers aren't going to be viable going forward as progress with them has been fairly stagnant it might be a far better solution to instead use a "Hamachi"-like setup for virtually routing traffic between clients through the server

Checklist

• Client can setup the virtual network and forward any messages through the server
• Server can handle mappings between virtual addresses and the actual clients
• Server can route messages through itself to the correct targets

Hey @jacobtread, Thanks for adopting SeaORM!
It's our pleasure to see more inspirational projects were built on top of SeaORM :)

Let us know if you have any feature recommendation or feedback. Your contribution is what drive us forward!

Some learning resources for you: Documentation, Tutorial, Cookbook, Q&A, Blog
Join our Discord server to chat with others in the SeaQL community!

Feel free to submit a PR to showcase your project, SeaQL/sea-orm#403.

Description

Warning
Support for crates.io has been discontinued

Pocket Relay is no longer compiling releases for crates.io as the last version released to crates.io was version 5.0, the crates.io release requirements adds additional requirements to the project that affect the project (i.e. requiring the dashboard compiled sources be included in the repository)

If you still want to compile it manually you can refer to the Manual Building
documentation.

Deprecating this allows the server to move forward and remove some of the restrictions imposed by requiring being able to build for crates.io

Checklist

• References to crates.io are removed from README
• Website is updated to remove references to crates.io

Description

See if its possible to use the in-game messaging system to create an "Origin linking system" that would allow users to send a sort of "one time password code" to the game through the in-game messaging system to allow that user to verify that they own the Origin account and set a password for that account through the dashboard

Checklist

• In-game messages can be used to receive messages for one time codes
• Dashboard can handle sending one time code messages
• Account passwords can be set using the one time passcode system

Description

Some users seem to have an issue where the synced Origin player data doesn't appear to be loaded before they reach the multiplayer menu. This needs to be investigated to determine whether a solution can be created to prevent needing to restart.

Possibly due to slight network delay? Or just the server getting ahead of itself? Needs further investigation

Current Solution

Users appear to see their player data properly after restarting the game/server so this might be a bug with the data not being inserted before authentication finishes?

Checklist

• Current data syncing solution is investigated for issues
• Origin player data is fully synced before authentication is completed and data is loaded

Description

Implementation of the server side handling for PocketRelay/Client#11 to decide which server information to use based on whether the client provides the expected header

Checklist

• Server correctly handles X-Pocket-Relay-Local-Http: true to ensure clients are served the expected information

Description

Currently the super admin role and super admin password are only assigned during the startup sequence of the app which is confusing to some users as they expect the password to be applied when an account is created.

This new feature will assign the role and password when an account is created as well as the usual startup sequence

Checklist

• Super admin password is assigned if a matching account is created
• Super admin role is assigned if a matching account is created

Description

Currently the server only supports syncing from official servers one time upon the first login of an origin account, if the player wants to get up to date progress from the official server they have to delete their account/database every time they want the new progress (Thus loosing any private server progress)

The goal for this improvement is to sort of "Diff" the results every time origin players login in order to keep local progress while also adding on any extra progress made on the official servers.

Note
Pocket Relay will NOT sync progress back to the official servers as its an infeasible implementation that would enable cheating while causing lots of development headaches. It is not a planned feature and likely wont ever be

Checklist

• Data can be loaded from official servers
• Progress can be diffed between the official servers and local copy in order to produce produce a shared data
• Merging data with the official server data doesn't cause issues with the local copy
• Feature is gated behind an optional flag

Description

Currently, as a fallback for the client failing to provide its public IP address when connecting to the server, the server will instead extract the IP address from the connection stream, when the server is NOT behind a reverse proxy this solution works well, however if the server is behind a reverse proxy it will mean that every connected client's public IP address will be set to the IP address of the reverse proxy server rather than the actual user meaning that attempting to connect to other players will simply silently fail.

Solution

The solution is to add an additional middleware extractor layer around the connection stream IP address extraction to support the https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/, https://doc.traefik.io/traefik/getting-started/faq/#what-are-the-forwarded-headers-when-proxying-http-requests Forwarded header set by reverse proxies, this feature should be gated by a configuration variable so that the server won't listen to the forwarded header unless a reverse proxy is used

Checklist

• IP Extraction is expanded to handle forwarded headers
• Configuration option is added for marking the server as behind a reverse proxy

Description

At some point I should go through and creating video walk-throughs for things like setting up servers and connecting clients etc to make a more easy to follow guide outside of the documentation (Should also be attached to the documentation with links)

Checklist

• Video on how to setup the server
• Video on how to setup and connect with the client
• Video on how to setup and connect with the client plugin
• Video on using the dashboard
• Video on configuring the server
• Documentation sections contain links to the relevant videos

Description

Currently the server uses blaze-pk for working with tdf encoding for packets. In order to unify it with the PocketArk implementation so that it can be kept more lock-step with all the new features and improvements it needs to be migrated from blaze-pk to tdf. This will allow reducing a lot of the boilerplate for created structures and bring in all the improvements that have been made to the codebase since PocketArk started re-implementing

Checklist

• Packet framing implementation moved from blaze-pk to server
• Routing implementation moved to server
• Ported serialization logic from blaze-pk to tdf