moulberry / graphite

1.19.1 high-performance Minecraft server

Graphite -- CURRENTLY ON HIATUS

1.19.1 Minecraft Server

TODO

• Complete protocol with all 1.19.1 Minecraft packets
• Command dispatch system
• Viewable objects (entities)
• Allow multiple players to connect (and see each other)
• Base lib crate that reexports everything
• ItemStacks with NBT
• Add layer for modifying the NBT of items easily
• Player Input Handling (Left/Right Click Air/Block)
• TextComponent things & macro
• Allow chunk/world modification
• Complete missing block placement (walls, double blocks, candles, etc.)
• "Extras" subproject - raycasting, collision, ...

Subprojects

• example_server: Example server using various Graphite components
• server: The minecraft server. Entities, chunks, players, all that good stuff
• concierge: Component that accepts new connections, handles status and login. Can be used to create proxies, servers, etc.
• protocol: The minecraft protocol
• net: Networking components and utilities
• binary: Zero-copy serialization
• command: Command dispatch and low-level creation
• command_derive: Attribute macro to easily create commands
• sticky: Collection(s) that guarantee the memory-location of its contents

Warning

Project is currently under heavy development, many things are completely non-functional

Building

Make sure to run git submodule update --init --recursive before building/running

How to run the example server

!!! Currently Graphite only supports modern versions of Linux with io_uring !!!
(An alternative network backend will be available eventually, but is not a priority)

$ cargo run --bin example_server

graphite's Issues

Players still receive viewable packets from despawned entities

Entities which have been despawned due to player movement will still send packets to players (for 1 tick)

This can be fixed by only sending viewable packets if the chunk is within BOTH chunk_view_position and new_chunk_view_position

Please open a Discord server for communication.

I believe a Discord server would be a great start for the community.

no readme

a README.md is a great way to tell people what the heck your project is, how to help build it, and how to test what you’ve made. once you’re at the point where others can help, i’d highly recommend making one

Potential OOM bug/exploit in graphite NBT

In crates/graphite_binary/src/nbt/decode.rs the read_list function uses Vec::with_capacity(length as _). However, length has no upper bound. I believe malicious input could potentially allocate i32::MAX * sizeof(usize) bytes.

The other read functions are correctly bounded.

Transmute between `Vec` types in graphite NBT

In crates/graphite_binary/src/nbt/decode.rs there is this

let vec: Vec<u8> = arr_bytes.into();
Ok(unsafe { std::mem::transmute(vec) })

Transmuting between Vec types is incorrect because #[repr(Rust)] types make no guarantee about their layout. The Rustonomicon has this to say:

So how do you know if the layouts are the same? For repr(C) types and repr(transparent) types, layout is precisely defined. But for your run-of-the-mill repr(Rust), it is not. Even different instances of the same generic type can have wildly different layout. Vec<i32> and Vec<u32> might have their fields in the same order, or they might not. The details of what exactly is and is not guaranteed for data layout are still being worked out over at the UCG WG.

Rewrite it in rust

Rust is blazingly fast and memory-efficient: with no runtime or garbage collector, it can power performance-critical services, run on embedded devices, and easily integrate with other languages.

Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time.

Rust has great documentation, a friendly compiler with useful error messages, and top-notch tooling — an integrated package manager and build tool, smart multi-editor support with auto-completion and type inspections, an auto-formatter, and more.