falconmc-dev/falconmc

An elegant and multiversioned Minecraft server written in Rust!

falconmc's Issues

Provide world.schem file

Currently it is not possible to run the server following the guide as it requests for a world.schem file. which though is unnecessary prevents the server from starting. Please provide this file so that I can run the server or remove it from the build so that others do not face the same issue as I have.

Feature: Onboarding Documentation

Motivation

Onboarding should ideally be a mostly unattended process. Our goal should be to minimize the number of questions incoming developers have, in order to free up time for more important questions and concerns.

Actions

• #15
• #16

Remarks

My goal with this issue is to provide documentation from first clone to first run. Broader documentation will be defined in another issue.

[Feature]: Improve issue templates

Improve issue templates using the new Github issue forms

[Feature]: CONTRIBUTING.md

Add a CONTRIBUTING.md with an overview of development workflow

Refactor packet pipeline

Solutions

• Buffer size: We use 4 buffers per connection, the default sizes of these buffers are 4kb. We currently shrink as quickly as possible after we exceed this size. Per connection there are two fixed buffers, one for writing data to and one for reading data to. The other two buffers are allowed to grow in size. Between the "fixed" and "dynamic" buffer, (de)compression may take place.

• New/Better traits: The mentioned six traits have been implemented for a number of base cases. The size function should return an exact size in bytes!! In cases where the packet contents do not depend on the size of the data, it does not have to be exact, but this tends to introduce bugs that are hard to track. If you are in the extremely rare case that you don't give an exact result, it is more efficient to give an upper limit. (This really should be avoided at all times!)

• Packet Caching: We'll hold off on this feature for a later time. moka has been selected as caching library, we will reintroduce this in a new pull request.

• Compression and encryption: Compression is fully supported although not used. Encryption requires authentication with mojang so we will also reintroduce this feature in a new pull request.

• Minor detail(s): falcon_send! and falcon_receive! are now back to being attribute macros! yay!

Problem

The current network pipeline that's implemented in Falcon isn't entirely optimal.

The (only?) example of being quite optimal for performance are the current attribute macros falcon_send! and falcon_receive!.
These expose a single function that then dispatches to the correct packet's writing or reading process according to protocol state and packet id without any more allocations and return as early as possible.

However, for the rest of the pipeline, at least the following should ideally be improved upon:

• Buffer size: We should strictly guard the buffer sizes used for every connection, I think these should be capped at 4kb or 8kb.
  When large packets need to be processed, these buffers may grow but should always be shrunk after. How to do this is still an open question that needs answering. ? Ideally we should also implement a metrics system to find out the average packet size sent by minecraft clients.

• New/Better traits: The current PacketEncode and PacketDecode traits aren't that well-crafted. These should be refactored into a much more modular system. I suggest using 6 traits (in 2 sets of 3) to do this (inspired by serde):

  • PacketRead, PacketWrite and PacketSize: Packet traits implemented by self-describing types (i.e. types that don't need extra data to be read or written, such as integers, uuid, boolean, ...).
  • PacketReadSeed, PacketWriteSeed and PacketSizeSeed: Packet traits implemented by types that need data not
    provided by the data stream or the type itself (e.g. strings have a maximum length that must be checked
    when reading or writing, Vecs usually need to be fed with another field in order to know how many elements they consist of).

  PacketSize and PacketSizeSeed may be required to either be exact or give an accurate estimate. I would rather choose the requirement of exactness but that is up to context and efficiency concerns. ?
  Alongside with this, the derive macros for these traits should be improved by a lot. Questions I have about these
  is how to deal with enums: How do enums appear in the minecraft protocol? ? How should we deal with these? ?
  And then the details of the macro itself, those belongs in a different issue however.

• Packet caching: How do we want this? I think we should only cache expensive packets
  that don't update constantly (such as world chunks). How this would work in the new pipeline I don't know yet. ?

• Compression and encryption: At some point we're also gonna need to deal with this, better to think
  about this early on. I did some research on this and it turns out streaming these two processes is very feasible.
  Question remains: How do they fit in our pipeline? Especially, how would caching would work with compression enabled? ?

• Minor detail(s): While the current falcon_send! and falcon_receive! macros are quite optimal for performance,
  they're not the most maintainer-friendly to work with. I made the mistake earlier of going from a macro that
  works on a module declaration to a function-like macro which doens't provide the best dev-experience for most IDEs.

To summarize

I think #21 is ready to be merged. Documentation still lacks for now.
Lots of questions that need to be answered first, I would love to hear everyone's opinion on this.

Document environment setup (installing Rust, etc.)

Version 1.8.9 gets stuck on join screen

Describe the bug
When I try to join the world using version 1.8.9, I can pass the login process and get stuck on world joining.
This should be impossible given that 1.8.9 is not yet supported.

To Reproduce
Launch Falcon and join with 1.8.9

Expected behavior
Immediately getting kicked for outdated client

Please complete the following information:

• Version: development branch