teampathfinders / mirai Goto Github PK

The lazy_static crate is deprecated and should be replaced with std::sync::OnceLock.

Add documentation comments to the remaining implemented and undocumented items.

Acknowledgements should be batched instead of sending a separate acknowledgement for each received reliable packet.

Describe the bug
The peek_u24_* methods in the BinaryRead trait don't read the triads using the correct endianness. The read_u24_* methods are correct however.

Currently the server does not support spitting packets yet. This should be supported when the server starts sending chunk packets.

Sometimes when the server is shutting down, it gets stuck presumably because one or more clients haven't properly disconnected.

When packets are fragmented due to them exceeding the MTU, the encryption checksums will no longer be correct. This causes Minecraft to get stuck on the "locating server" screen when the server attempts to send a CreativeContent packet.

I have suspicions that this is related to either data not being split correctly, therefore becoming corrupted when reassembling compounds, or the send counter not being incremented properly.

It is also possible that every packet fragment needs to be encrypted separately, but this seems unlikely since it would interfere with the RakNet implementation.

The server currently only supports Deflate compression. Snappy is another supported algorithm in the protocol, it should be implemented.

Since the codebase switched to using the new BinaryWrite and BinaryRead traits and removed the old NBT serialiser, the StartGame packet hasn't been fully implemented.

This packet needs to be implemented to complete the rest of the login sequence.

Describe the bug
There are several typos in the documentation of some types and methods. For example, it seems like a search and replace may have replaced a lot of occurrences of "packets" with "raknet" instead.

The client crashes whenever the ServerToClientHandshake packet is sent

Some NBT types don't have clearly defined structures. The BlockStates type in pyro_level is an example of this. Instead of storing every single possible key, there should be some general nbt::Value type that can be stored in a map.

Snappy isn't supported by the server at the moment, implement Snappy compression and decompression

The chunk loader should be moved into its own module.
So should the command related utilities

Currently a single task handles the received packets in serial. This completely freezes processing a for a single client if some packet takes long to process, therefore a new task should be spawned for every received packet. The downside I see to this is that this might not preserve ordering of packets, due to the unpredictable nature of multithreading.

The RakNet layer could keep using a single task for processing as I don't see any issues with that and no packets take a long time to process since it's all just preprocessing anyways.

Decrease the amount of shared state in the server and instead use smaller workers with messaging channels. Since the Raknet and Bedrock separation, this has already been partially implemented for the clients.

An example I also thought of is getting rid of the Arc that currently wraps a user and send commands to the session instead of calling its functions directly.

Often when an error occurs with the database, complete garbage will be printed to the terminal. I assume this has to do with a bug in how the errors are translated and passed to Rust

Describe the bug
Since the removal of the Redis replication layer, the build and run instructions in the README are outdated. The Docker compose command will not work because the compose file has been removed. And it is no longer necessary to set up Redis.

Additionally, a call for contribution should be added and a list of contributors can be added to the bottom to reward contributors.

Add support for resource packs by properly implementing ResourcePacksInfo, ResourcePackStack and ResourcePackClientResponse.
Currently the server skips most of this.

The implementation for this should also include a fix for the unexpected packet issue. Currently the server assumes it will receive a cache status packet while sometimes the client may send a resource pack response instead.

For some reason it is possible to open a filesystem database multiple times.
LevelDB doesn't prevent it like it's supposed to.

This generally causes corruption.

It seems like Minecraft uses varints to encode strings in names, instead of shorts

https://github.com/Sandertv/gophertunnel/blob/5e43f0cb905f8cc8f6554283ba32fbbd732322c7/minecraft/nbt/encoding.go#L150

The client sends its protocol version in the RequestNetworkSettings packet.
If this version does not match the server's, the client should be disconnected using a PlayStatus packet.

Send NACKs in case of packet loss.

Isolate Raknet from the rest of the server and put it in its own repository so it can be reused.

Commands do not appear if the command permission level is set to anything above visitor.

Implement packet encryption and decryption

The serialized_size function should be removed and replaced by the new size_hint function in the Serialize trait which will automatically allocate before serializing.

Use an action like https://github.com/marketplace/actions/rust-problem-matchers to add failure descriptions to the workflow checks

Packets can be decompressed but not compressed currently, implement client-bound packet compression.

All code using thiserror should be refactored to use anyhow.

Instead of performing many allocations, memory should be stored in some kind of arena or pool

PString is the custom version of String that uses the server's memory pool

Sometimes connecting fails with the following error:

thread '[5]' panicked at core\src\network\user.rs:304:29:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This only seems to happen when the client for some reason fails to connect the first time and then you try to connect again. I assume this might be caused by Minecraft trying to continue where it left off previously (in this case it didn't manage to send the login packet) instead of fully reconnecting. So Minecraft would have already sent a disconnect packet causing the server to fully destroy all client data, but then on the second connection attempt, Minecraft immediately sends a login packet instead of first initiating the RakNet connection.

This seems more like a bug in the game than in the server and should probably be explicitly handled by the server by simply disconnecting the client and forcing them to fully reconnect.

Is your feature request related to a problem? Please describe.
Currently every command is available to all players regardless of their permissions.

Describe the solution you'd like
Ideally the server should understand completely arbitrary permissions that can alter access to individual commands, i.e. a user could create a "kick" permission that allows all users that have this permission to use the /kick command.

Describe alternatives you've considered
Alternatively, we could also implement the three different permission levels implemented by the base game, but I think that would be too restrictive for larger custom servers.

Add a README to the repository.