- Fix performance issues related to writing individual bytes instead of
using `Write::write_all`.
- Make manual implementations of `Encode` and `Decode` easier:
- Remove `encoded_len` method from `Encode`
- Split `Packet` trait into `EncodePacket` and `DecodePacket`.
- Simplify derive macros.
- automatically handle CloseContainer packet so the client updates open_inventory
- Use `Option<InventoryId>` for `open_inventory` on client
Co-authored-by: Ryan Johnson <ryanj00a@gmail.com>
This PR also includes the Criterion benchmark.
## Before this commit
> Benchmarking BlockState::to_kind
> Benchmarking BlockState::to_kind: Warming up for 3.0000 s Benchmarking
BlockState::to_kind: Collecting 100 samples in estimated 20.045 s (273k
iterations) Benchmarking BlockState::to_kind: Analyzing
> BlockState::to_kind time: [68.925 µs 69.202 µs 69.477 µs]
>
> Found 5 outliers among 100 measurements (5.00%)
> 4 (4.00%) high mild
> 1 (1.00%) high severe
## After this commit
> Benchmarking BlockState::to_kind
> Benchmarking BlockState::to_kind: Warming up for 3.0000 s Benchmarking
BlockState::to_kind: Collecting 100 samples in estimated 20.010 s (3.8M
iterations) Benchmarking BlockState::to_kind: Analyzing
> BlockState::to_kind time: [1.5814 µs 1.5859 µs 1.5912 µs]
> change: [-97.692% -97.678% -97.666%] (p = 0.00 < 0.05)
> Performance has improved.
> Found 4 outliers among 100 measurements (4.00%)
> 4 (4.00%) high mild
Co-authored-by: Ryan Johnson <ryanj00a@gmail.com>
- Implement `encoded_len` for packet enums.
- Fix bug in `has_next_packet` causing a later `unwrap` to panic.
- Add robust `encoded_len` check in `PacketEncoder` for debug builds.
- Split packet inspector regex into separate "inclusive" and "exclusive"
arguments because the `regex` crate does not support negative lookahead.
- Better `Debug` impls for `Ident` and `Compound`.
- Remove read/write timeouts from packet inspector.
Previously, the chunk data cache was regenerated at the end of each tick
every time a block or biome was modified in a chunk. This causes
performance problems in situations where chunks are being modified every
tick, like the conway example or redstone machines.
This changes things so that the chunk data packet is regenerated only
when a client actually needs to load the chunk. This isn't perfect
because the regeneration cannot happen in parallel, but the benefits
outweigh the costs. (The chunk data packet _is_ generated in parallel
when the chunk is first created. There is also some parallelism when
clients are loading different chunks. The packet cache is guarded by a
`Mutex`.)
This has revealed that compression is surprisingly slow. This should be
investigated later.
Closes#84
# Changes
- Implemented new algorithm for tracking loaded entities and chunks.
- The client does not need to maintain a list of loaded chunks and
entities anymore, as this information can be inferred using carefully
maintained data from the previous tick.
- Chunks are used as a spatial partition for entities. Entity visibility
is now based on chunk visibility rather than the euclidean distance to
clients.
- The BVH is no longer strictly necessary, so it has been moved to the
new `valence_spatial_index` crate.
- The API has been generalized to support things other than entities.
The crate does not have a dependency on the main `valence` crate.
- Chunk, entity, and player list packets are now aggressively cached to
increase performance.
- Chunk packets now include some filler light data. This makes the
vanilla client lag a lot less.
- Entities and chunks must now be marked as deleted before they are
removed.
- Improved `ChunkPos` interface.
- Added function to get the duration per tick.
- Added `Index` and `IndexMut` impls to collection types.
As a result of the above changes, performance under heavy load has
increased significantly. With the rust-mc-bot test on my machine, I went
from a max of ~1000 players to ~4000 players.
# Noteworthy Changes
- Simplified the `client` module and update procedure. Sending packets
is not deferred unless necessary.
- Client events are no longer buffered in `Client` before reaching the
user.
- Expanded `ClientEvent` to account for most packets.
- Most types containing custom `state` now implement `Deref` and
`DerefMut`. This means you don't have to write `.state` all over the
place. `Server` was excluded from this because it does not play well
with the borrow checker.
- Fixed bugs related to entity visibility.
- Client now correctly holds the semaphore permit from the initial
connection.
- Other miscellaneous API changes throughout the project.
# Known Issues
- Inventory stuff is still incomplete. The inventory examples have been
temporarily disabled.
The `tracing` crate seems to be the go-to
logging/profiling/instrumentation solution nowadays. Perhaps in the
future we could use `tracing` for profiling instead of (or in addition
to) the `perf`-based `cargo flamegraph` command. This would sidestep the
issue of `rayon` polluting the output. I conducted an initial experiment
by adding some more spans but wasn't very happy with the result.
Log messages have also been improved. There is some additional context
and events are raised when clients are added/removed from the server.
Closes#83
This PR aims to move all of Valence's networking code to the new
`valence_protocol` crate. Anything not specific to valence is going in
the new crate. It also redesigns the way packets are defined and makes a
huge number of small additions and improvements. It should be much
easier to see where code is supposed to go from now on.
`valence_protocol` is a new library which enables interactions with
Minecraft's protocol. It is completely decoupled from valence and can be
used to build new clients, servers, tools, etc.
There are two additions that will help with #5 especially:
- It is now easy to define new packets or modifications of existing
packets. Not all packets need to be bidirectional.
- The `CachedEncode` type has been created. This is used to safely cache
redundant calls to `Encode::encode`.
