valence/src/config.rs

424 lines
16 KiB
Rust
Raw Normal View History

2022-07-15 16:18:20 +10:00
//! Configuration for the server.
use std::borrow::Cow;
use std::net::{IpAddr, Ipv4Addr, SocketAddr, SocketAddrV4};
2022-04-15 07:55:45 +10:00
use async_trait::async_trait;
use serde::Serialize;
2022-04-15 07:55:45 +10:00
use tokio::runtime::Handle as TokioHandle;
use uuid::Uuid;
use valence_protocol::text::Text;
use valence_protocol::username::Username;
use valence_protocol::MAX_PACKET_SIZE;
2022-04-15 07:55:45 +10:00
use crate::biome::Biome;
use crate::dimension::Dimension;
use crate::server::{NewClientData, Server, SharedServer};
2022-07-18 14:29:44 +10:00
use crate::{Ticks, STANDARD_TPS};
2022-04-15 07:55:45 +10:00
2022-07-16 13:40:39 +10:00
/// A trait for the configuration of a server.
///
2022-07-11 22:08:02 +10:00
/// This trait uses the [async_trait] attribute macro. It is exported at the
2022-09-02 17:06:45 +10:00
/// root of this crate. async_trait will be removed once async fns in traits
/// are stabilized.
2022-07-11 22:08:02 +10:00
///
/// [async_trait]: https://docs.rs/async-trait/latest/async_trait/
#[async_trait]
#[allow(unused_variables)]
pub trait Config: Sized + Send + Sync + 'static {
2022-07-28 12:21:11 +10:00
/// Custom state to store with the [`Server`].
type ServerState: Send + Sync;
/// Custom state to store with every [`Client`](crate::client::Client).
type ClientState: Default + Send + Sync;
/// Custom state to store with every [`Entity`](crate::entity::Entity).
type EntityState: Send + Sync;
/// Custom state to store with every [`World`](crate::world::World).
type WorldState: Send + Sync;
/// Custom state to store with every
/// [`LoadedChunk`](crate::chunk::LoadedChunk).
2022-07-28 12:21:11 +10:00
type ChunkState: Send + Sync;
/// Custom state to store with every
/// [`PlayerList`](crate::player_list::PlayerList).
2022-08-10 07:44:04 +10:00
type PlayerListState: Send + Sync;
2022-07-16 13:40:39 +10:00
/// Called once at startup to get the maximum number of simultaneous
/// connections allowed to the server. This includes all
/// connections, not just those past the login stage.
///
/// You will want this value to be somewhere above the maximum number of
/// players, since status pings should still succeed even when the server is
/// full.
Redesign packet processing and improve `Client` update procedure. (#146) Closes #82 Closes #43 Closes #64 # Changes and Improvements - Packet encoding/decoding happens within `Client` instead of being sent over a channel first. This is better for performance and lays the groundwork for #83. - Reduce the amount of copying necessary by leveraging the `bytes` crate and recent changes to `EncodePacket`. Performance is noticeably improved with maximum players in the `rust-mc-bot` test going from 750 to 1050. - Packet encoding/decoding code is decoupled from IO. This is easier to understand and more suitable for a future protocol lib. - Precise control over the number of bytes that are buffered for sending/receiving. This is important for limiting maximum memory usage correctly. - "packet controllers" are introduced, which are convenient structures for managing packet IO before and during the play state. - `byte_channel` module is created to help implement the `PlayPacketController`. This is essentially a channel of bytes implemented with an `Arc<Mutex<BytesMut>>`. - Error handling in the update procedure for clients was improved using `anyhow::Result<()>` to exit as early as possible. The `client` module is a bit cleaner as a result. - The `LoginPlay` packet is always sent before all other play packets. We no longer have to worry about the behavior of packets sent before that packet. Most packet deferring performed currently can be eliminated. - The packet_inspector was rewritten in response to the above changes. - Timeouts on IO operations behave better. # Known Issues - The packet_inspector now re-encodes packets rather than just decoding them. This will cause problems when trying to use it with the vanilla server because there are missing clientbound packets and other issues. This will be fixed when the protocol module is moved to a separate crate.
2022-11-01 21:11:51 +11:00
///
/// # Default Implementation
///
/// Currently returns `1024`. This may change in a future version.
fn max_connections(&self) -> usize {
1024
}
2022-04-15 07:55:45 +10:00
/// Called once at startup to get the socket address the server will
/// be bound to.
2022-04-15 07:55:45 +10:00
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// Returns `0.0.0.0:25565` to listen on every available network interface.
fn address(&self) -> SocketAddr {
SocketAddrV4::new(Ipv4Addr::new(0, 0, 0, 0), 25565).into()
2022-04-15 07:55:45 +10:00
}
/// Called once at startup to get the tick rate, which is the number of game
/// updates that should occur in one second.
2022-04-15 07:55:45 +10:00
///
/// On each game update (tick), the server is expected to update game logic
/// and respond to packets from clients. Once this is complete, the server
/// will sleep for any remaining time until a full tick has passed.
2022-04-15 07:55:45 +10:00
///
/// The tick rate must be greater than zero.
2022-04-15 07:55:45 +10:00
///
/// Note that the official Minecraft client only processes packets at 20hz,
/// so there is little benefit to a tick rate higher than 20.
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
2022-07-18 14:29:44 +10:00
/// Returns [`STANDARD_TPS`].
fn tick_rate(&self) -> Ticks {
2022-07-18 14:29:44 +10:00
STANDARD_TPS
2022-04-15 07:55:45 +10:00
}
/// Called to get the connection mode option, which determines if client
/// authentication and encryption should take place and if the server
/// should get the player data from a proxy.
2022-04-15 07:55:45 +10:00
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// Returns [`ConnectionMode::Online`].
fn connection_mode(&self) -> ConnectionMode {
ConnectionMode::Online
2022-04-15 07:55:45 +10:00
}
/// Obtains the compression threshold to use for compressing packets. For a
/// compression threshold of `Some(N)`, packets with encoded lengths >= `N`
/// are compressed while all others are not. `None` disables compression.
///
/// # Default Implementation
///
/// If the connection mode is [`ConnectionMode::Online`], `Some(256)` is
/// returned. Otherwise, compression is disabled.
fn compression_threshold(&self) -> Option<u32> {
match self.connection_mode() {
ConnectionMode::Online => Some(256),
_ => None,
}
}
/// Called upon every client login to obtain the full URL to use for session
/// server requests. This is done to authenticate player accounts. This
/// method is not called unless [online mode] is enabled.
///
/// It is assumed that upon successful request, a structure matching the
/// description in the [wiki](https://wiki.vg/Protocol_Encryption#Server) was obtained.
/// Providing a URL that does not return such a structure will result in a
/// disconnect for every client that connects.
///
/// The arguments are described in the linked wiki article.
///
/// # Default Implementation
///
/// Uses the official Minecraft session server. This is formatted as
/// `https://sessionserver.mojang.com/session/minecraft/hasJoined?username=<username>&serverId=<auth-digest>&ip=<player-ip>`.
///
/// [online mode]: crate::config::ConnectionMode::Online
fn session_server(
&self,
server: &SharedServer<Self>,
username: Username<&str>,
auth_digest: &str,
player_ip: &IpAddr,
) -> String {
if self.prevent_proxy_connections() {
format!("https://sessionserver.mojang.com/session/minecraft/hasJoined?username={username}&serverId={auth_digest}&ip={player_ip}")
} else {
format!("https://sessionserver.mojang.com/session/minecraft/hasJoined?username={username}&serverId={auth_digest}")
}
}
/// Called from the default implementation of [`Config::session_server`] to
/// get the "prevent-proxy-connections" option, which determines if client
/// IP validation should take place.
///
/// When `prevent_proxy_connections` is enabled, clients can no longer
/// log-in if they connected to the yggdrasil server using a different
/// IP.
///
/// # Default Implementation
///
/// Proxy connections are allowed.
///
/// Returns `false`.
fn prevent_proxy_connections(&self) -> bool {
false
}
Redesign packet processing and improve `Client` update procedure. (#146) Closes #82 Closes #43 Closes #64 # Changes and Improvements - Packet encoding/decoding happens within `Client` instead of being sent over a channel first. This is better for performance and lays the groundwork for #83. - Reduce the amount of copying necessary by leveraging the `bytes` crate and recent changes to `EncodePacket`. Performance is noticeably improved with maximum players in the `rust-mc-bot` test going from 750 to 1050. - Packet encoding/decoding code is decoupled from IO. This is easier to understand and more suitable for a future protocol lib. - Precise control over the number of bytes that are buffered for sending/receiving. This is important for limiting maximum memory usage correctly. - "packet controllers" are introduced, which are convenient structures for managing packet IO before and during the play state. - `byte_channel` module is created to help implement the `PlayPacketController`. This is essentially a channel of bytes implemented with an `Arc<Mutex<BytesMut>>`. - Error handling in the update procedure for clients was improved using `anyhow::Result<()>` to exit as early as possible. The `client` module is a bit cleaner as a result. - The `LoginPlay` packet is always sent before all other play packets. We no longer have to worry about the behavior of packets sent before that packet. Most packet deferring performed currently can be eliminated. - The packet_inspector was rewritten in response to the above changes. - Timeouts on IO operations behave better. # Known Issues - The packet_inspector now re-encodes packets rather than just decoding them. This will cause problems when trying to use it with the vanilla server because there are missing clientbound packets and other issues. This will be fixed when the protocol module is moved to a separate crate.
2022-11-01 21:11:51 +11:00
/// Called once at startup to get the maximum capacity (in bytes) of the
/// buffer used to hold incoming packet data.
2022-04-15 07:55:45 +10:00
///
2022-09-02 17:06:45 +10:00
/// A larger capacity reduces the chance that a client needs to be
Redesign packet processing and improve `Client` update procedure. (#146) Closes #82 Closes #43 Closes #64 # Changes and Improvements - Packet encoding/decoding happens within `Client` instead of being sent over a channel first. This is better for performance and lays the groundwork for #83. - Reduce the amount of copying necessary by leveraging the `bytes` crate and recent changes to `EncodePacket`. Performance is noticeably improved with maximum players in the `rust-mc-bot` test going from 750 to 1050. - Packet encoding/decoding code is decoupled from IO. This is easier to understand and more suitable for a future protocol lib. - Precise control over the number of bytes that are buffered for sending/receiving. This is important for limiting maximum memory usage correctly. - "packet controllers" are introduced, which are convenient structures for managing packet IO before and during the play state. - `byte_channel` module is created to help implement the `PlayPacketController`. This is essentially a channel of bytes implemented with an `Arc<Mutex<BytesMut>>`. - Error handling in the update procedure for clients was improved using `anyhow::Result<()>` to exit as early as possible. The `client` module is a bit cleaner as a result. - The `LoginPlay` packet is always sent before all other play packets. We no longer have to worry about the behavior of packets sent before that packet. Most packet deferring performed currently can be eliminated. - The packet_inspector was rewritten in response to the above changes. - Timeouts on IO operations behave better. # Known Issues - The packet_inspector now re-encodes packets rather than just decoding them. This will cause problems when trying to use it with the vanilla server because there are missing clientbound packets and other issues. This will be fixed when the protocol module is moved to a separate crate.
2022-11-01 21:11:51 +11:00
/// disconnected due to the buffer being full, but increases potential
/// memory usage.
2022-04-15 07:55:45 +10:00
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// An unspecified value is returned that should be adequate for most
/// situations. This default may change in future versions.
Redesign packet processing and improve `Client` update procedure. (#146) Closes #82 Closes #43 Closes #64 # Changes and Improvements - Packet encoding/decoding happens within `Client` instead of being sent over a channel first. This is better for performance and lays the groundwork for #83. - Reduce the amount of copying necessary by leveraging the `bytes` crate and recent changes to `EncodePacket`. Performance is noticeably improved with maximum players in the `rust-mc-bot` test going from 750 to 1050. - Packet encoding/decoding code is decoupled from IO. This is easier to understand and more suitable for a future protocol lib. - Precise control over the number of bytes that are buffered for sending/receiving. This is important for limiting maximum memory usage correctly. - "packet controllers" are introduced, which are convenient structures for managing packet IO before and during the play state. - `byte_channel` module is created to help implement the `PlayPacketController`. This is essentially a channel of bytes implemented with an `Arc<Mutex<BytesMut>>`. - Error handling in the update procedure for clients was improved using `anyhow::Result<()>` to exit as early as possible. The `client` module is a bit cleaner as a result. - The `LoginPlay` packet is always sent before all other play packets. We no longer have to worry about the behavior of packets sent before that packet. Most packet deferring performed currently can be eliminated. - The packet_inspector was rewritten in response to the above changes. - Timeouts on IO operations behave better. # Known Issues - The packet_inspector now re-encodes packets rather than just decoding them. This will cause problems when trying to use it with the vanilla server because there are missing clientbound packets and other issues. This will be fixed when the protocol module is moved to a separate crate.
2022-11-01 21:11:51 +11:00
fn incoming_capacity(&self) -> usize {
MAX_PACKET_SIZE as usize
2022-04-15 07:55:45 +10:00
}
Redesign packet processing and improve `Client` update procedure. (#146) Closes #82 Closes #43 Closes #64 # Changes and Improvements - Packet encoding/decoding happens within `Client` instead of being sent over a channel first. This is better for performance and lays the groundwork for #83. - Reduce the amount of copying necessary by leveraging the `bytes` crate and recent changes to `EncodePacket`. Performance is noticeably improved with maximum players in the `rust-mc-bot` test going from 750 to 1050. - Packet encoding/decoding code is decoupled from IO. This is easier to understand and more suitable for a future protocol lib. - Precise control over the number of bytes that are buffered for sending/receiving. This is important for limiting maximum memory usage correctly. - "packet controllers" are introduced, which are convenient structures for managing packet IO before and during the play state. - `byte_channel` module is created to help implement the `PlayPacketController`. This is essentially a channel of bytes implemented with an `Arc<Mutex<BytesMut>>`. - Error handling in the update procedure for clients was improved using `anyhow::Result<()>` to exit as early as possible. The `client` module is a bit cleaner as a result. - The `LoginPlay` packet is always sent before all other play packets. We no longer have to worry about the behavior of packets sent before that packet. Most packet deferring performed currently can be eliminated. - The packet_inspector was rewritten in response to the above changes. - Timeouts on IO operations behave better. # Known Issues - The packet_inspector now re-encodes packets rather than just decoding them. This will cause problems when trying to use it with the vanilla server because there are missing clientbound packets and other issues. This will be fixed when the protocol module is moved to a separate crate.
2022-11-01 21:11:51 +11:00
/// Called once at startup to get the maximum capacity (in bytes) of the
/// buffer used to hold outgoing packets.
2022-04-15 07:55:45 +10:00
///
2022-09-02 17:06:45 +10:00
/// A larger capacity reduces the chance that a client needs to be
Redesign packet processing and improve `Client` update procedure. (#146) Closes #82 Closes #43 Closes #64 # Changes and Improvements - Packet encoding/decoding happens within `Client` instead of being sent over a channel first. This is better for performance and lays the groundwork for #83. - Reduce the amount of copying necessary by leveraging the `bytes` crate and recent changes to `EncodePacket`. Performance is noticeably improved with maximum players in the `rust-mc-bot` test going from 750 to 1050. - Packet encoding/decoding code is decoupled from IO. This is easier to understand and more suitable for a future protocol lib. - Precise control over the number of bytes that are buffered for sending/receiving. This is important for limiting maximum memory usage correctly. - "packet controllers" are introduced, which are convenient structures for managing packet IO before and during the play state. - `byte_channel` module is created to help implement the `PlayPacketController`. This is essentially a channel of bytes implemented with an `Arc<Mutex<BytesMut>>`. - Error handling in the update procedure for clients was improved using `anyhow::Result<()>` to exit as early as possible. The `client` module is a bit cleaner as a result. - The `LoginPlay` packet is always sent before all other play packets. We no longer have to worry about the behavior of packets sent before that packet. Most packet deferring performed currently can be eliminated. - The packet_inspector was rewritten in response to the above changes. - Timeouts on IO operations behave better. # Known Issues - The packet_inspector now re-encodes packets rather than just decoding them. This will cause problems when trying to use it with the vanilla server because there are missing clientbound packets and other issues. This will be fixed when the protocol module is moved to a separate crate.
2022-11-01 21:11:51 +11:00
/// disconnected due to the buffer being full, but increases potential
/// memory usage.
2022-04-15 07:55:45 +10:00
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// An unspecified value is returned that should be adequate for most
/// situations. This default may change in future versions.
Redesign packet processing and improve `Client` update procedure. (#146) Closes #82 Closes #43 Closes #64 # Changes and Improvements - Packet encoding/decoding happens within `Client` instead of being sent over a channel first. This is better for performance and lays the groundwork for #83. - Reduce the amount of copying necessary by leveraging the `bytes` crate and recent changes to `EncodePacket`. Performance is noticeably improved with maximum players in the `rust-mc-bot` test going from 750 to 1050. - Packet encoding/decoding code is decoupled from IO. This is easier to understand and more suitable for a future protocol lib. - Precise control over the number of bytes that are buffered for sending/receiving. This is important for limiting maximum memory usage correctly. - "packet controllers" are introduced, which are convenient structures for managing packet IO before and during the play state. - `byte_channel` module is created to help implement the `PlayPacketController`. This is essentially a channel of bytes implemented with an `Arc<Mutex<BytesMut>>`. - Error handling in the update procedure for clients was improved using `anyhow::Result<()>` to exit as early as possible. The `client` module is a bit cleaner as a result. - The `LoginPlay` packet is always sent before all other play packets. We no longer have to worry about the behavior of packets sent before that packet. Most packet deferring performed currently can be eliminated. - The packet_inspector was rewritten in response to the above changes. - Timeouts on IO operations behave better. # Known Issues - The packet_inspector now re-encodes packets rather than just decoding them. This will cause problems when trying to use it with the vanilla server because there are missing clientbound packets and other issues. This will be fixed when the protocol module is moved to a separate crate.
2022-11-01 21:11:51 +11:00
fn outgoing_capacity(&self) -> usize {
MAX_PACKET_SIZE as usize * 4
2022-04-15 07:55:45 +10:00
}
/// Called once at startup to get a handle to the tokio runtime the server
/// will use.
2022-04-15 07:55:45 +10:00
///
/// If a handle is not provided, the server will create its own tokio
/// runtime.
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// Returns `None`.
fn tokio_handle(&self) -> Option<TokioHandle> {
None
2022-04-15 07:55:45 +10:00
}
/// Called once at startup to get the list of [`Dimension`]s usable on the
/// server.
2022-04-15 07:55:45 +10:00
///
2022-07-11 22:08:02 +10:00
/// The dimensions returned by [`SharedServer::dimensions`] will be in the
/// same order as the `Vec` returned by this function.
///
2022-07-11 22:08:02 +10:00
/// The number of elements in the returned `Vec` must be in `1..=u16::MAX`.
2022-04-15 07:55:45 +10:00
/// Additionally, the documented requirements on the fields of [`Dimension`]
/// must be met.
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// Returns `vec![Dimension::default()]`.
fn dimensions(&self) -> Vec<Dimension> {
vec![Dimension::default()]
2022-04-15 07:55:45 +10:00
}
/// Called once at startup to get the list of [`Biome`]s usable on the
/// server.
2022-04-15 07:55:45 +10:00
///
2022-07-11 22:08:02 +10:00
/// The biomes returned by [`SharedServer::biomes`] will be in the same
/// order as the `Vec` returned by this function.
///
2022-07-11 22:08:02 +10:00
/// The number of elements in the returned `Vec` must be in `1..=u16::MAX`.
2022-04-15 07:55:45 +10:00
/// Additionally, the documented requirements on the fields of [`Biome`]
/// must be met.
2022-04-15 07:55:45 +10:00
///
2022-10-14 12:19:35 +11:00
/// **NOTE**: As of 1.19.2, there is a bug in the client which prevents
/// joining the game when a biome named "minecraft:plains" is not present.
/// Ensure there is a biome named "plains".
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// Returns `vec![Biome::default()]`.
fn biomes(&self) -> Vec<Biome> {
vec![Biome::default()]
2022-04-15 07:55:45 +10:00
}
/// Called when the server receives a Server List Ping query.
/// Data for the response can be provided or the query can be ignored.
2022-04-15 07:55:45 +10:00
///
/// This method is called from within a tokio runtime.
///
2022-04-15 07:55:45 +10:00
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// The query is ignored.
async fn server_list_ping(
&self,
2022-07-16 13:40:39 +10:00
shared: &SharedServer<Self>,
remote_addr: SocketAddr,
2022-08-15 08:18:22 +10:00
protocol_version: i32,
) -> ServerListPing {
ServerListPing::Ignore
}
2022-04-15 07:55:45 +10:00
/// Called asynchronously for each client after successful authentication
2022-07-11 22:08:02 +10:00
/// (if online mode is enabled) to determine if they can join
/// the server. On success, the new client is added to the server's
/// [`Clients`]. If this method returns with `Err(reason)`, then the
/// client is immediately disconnected with the given reason.
2022-04-15 07:55:45 +10:00
///
/// This method is the appropriate place to perform asynchronous
/// operations such as database queries which may take some time to
/// complete.
2022-04-15 07:55:45 +10:00
///
/// This method is called from within a tokio runtime.
///
2022-04-15 07:55:45 +10:00
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// The client is allowed to join unconditionally.
2022-07-11 22:08:02 +10:00
///
/// [`Clients`]: crate::client::Clients
2022-07-16 13:40:39 +10:00
async fn login(&self, shared: &SharedServer<Self>, ncd: &NewClientData) -> Result<(), Text> {
Ok(())
}
2022-04-15 07:55:45 +10:00
/// Called after the server is created, but prior to accepting connections
/// and entering the update loop.
2022-04-15 07:55:45 +10:00
///
/// This is useful for performing initialization work with a guarantee that
/// no connections to the server will be made until this function returns.
///
/// This method is called from within a tokio runtime.
///
/// # Default Implementation
///
/// The default implementation does nothing.
2022-07-16 13:40:39 +10:00
fn init(&self, server: &mut Server<Self>) {}
2022-04-15 07:55:45 +10:00
/// Called once at the beginning of every server update (also known as
2022-07-11 22:08:02 +10:00
/// "tick"). This is likely where the majority of your code will be.
2022-04-15 07:55:45 +10:00
///
2022-07-11 22:08:02 +10:00
/// The frequency of ticks can be configured by [`Self::tick_rate`].
///
/// This method is called from within a tokio runtime.
2022-04-15 07:55:45 +10:00
///
/// # Default Implementation
2022-07-11 22:08:02 +10:00
///
/// The default implementation does nothing.
fn update(&self, server: &mut Server<Self>) {}
2022-04-15 07:55:45 +10:00
}
2022-07-11 22:08:02 +10:00
/// The result of the [`server_list_ping`](Config::server_list_ping) callback.
2022-09-08 04:36:12 +10:00
#[allow(clippy::large_enum_variant)]
#[derive(Clone, Debug)]
pub enum ServerListPing<'a> {
2022-04-15 07:55:45 +10:00
/// Responds to the server list ping with the given information.
Respond {
2022-07-11 22:08:02 +10:00
/// Displayed as the number of players on the server.
2022-04-15 07:55:45 +10:00
online_players: i32,
2022-07-11 22:08:02 +10:00
/// Displayed as the maximum number of players allowed on the server at
/// a time.
2022-04-15 07:55:45 +10:00
max_players: i32,
/// The list of players visible by hovering over the player count.
///
/// Has no effect if this list is empty.
player_sample: Cow<'a, [PlayerSampleEntry<'a>]>,
2022-07-11 22:08:02 +10:00
/// A description of the server.
2022-04-15 07:55:45 +10:00
description: Text,
/// The server's icon as the bytes of a PNG image.
/// The image must be 64x64 pixels.
///
/// No icon is used if the value is `None`.
favicon_png: Option<Cow<'a, [u8]>>,
2022-04-15 07:55:45 +10:00
},
/// Ignores the query and disconnects from the client.
Ignore,
}
/// Describes how new connections to the server are handled.
#[non_exhaustive]
#[derive(Clone, PartialEq, Default)]
pub enum ConnectionMode {
/// The "online mode" fetches all player data (username, UUID, and skin)
/// from the [configured session server] and enables encryption.
///
/// This mode should be used for all publicly exposed servers which are not
/// behind a proxy.
///
/// [configured session server]: Config::session_server
#[default]
Online,
/// Disables client authentication with the configured session server.
/// Clients can join with any username and UUID they choose, potentially
/// gaining privileges they would not otherwise have. Additionally,
/// encryption is disabled and Minecraft's default skins will be used.
///
/// This mode should be used for development purposes only and not for
/// publicly exposed servers.
Offline,
/// This mode should be used under one of the following situations:
/// - The server is behind a [BungeeCord]/[Waterfall] proxy with IP
/// forwarding enabled.
/// - The server is behind a [Velocity] proxy configured to use the `legacy`
/// forwarding mode.
///
/// All player data (username, UUID, and skin) is fetched from the proxy,
/// but no attempt is made to stop connections originating from
/// elsewhere. As a result, you must ensure clients connect through the
/// proxy and are unable to connect to the server directly. Otherwise,
/// clients can use any username or UUID they choose similar to
/// [`ConnectionMode::Offline`].
///
/// To protect against this, a firewall can be used. However,
/// [`ConnectionMode::Velocity`] is recommended as a secure alternative.
///
/// [BungeeCord]: https://www.spigotmc.org/wiki/bungeecord/
/// [Waterfall]: https://github.com/PaperMC/Waterfall
/// [Velocity]: https://velocitypowered.com/
BungeeCord,
/// This mode is used when the server is behind a [Velocity] proxy
/// configured with the forwarding mode `modern`.
///
/// All player data (username, UUID, and skin) is fetched from the proxy and
/// all connections originating from outside Velocity are blocked.
///
/// [Velocity]: https://velocitypowered.com/
Velocity {
/// The secret key used to prevent connections from outside Velocity.
/// The proxy and Valence must be configured to use the same secret key.
secret: String,
},
}
/// Represents an individual entry in the player sample.
#[derive(Clone, Debug, Serialize)]
pub struct PlayerSampleEntry<'a> {
/// The name of the player.
///
/// This string can contain
/// [legacy formatting codes](https://minecraft.fandom.com/wiki/Formatting_codes).
pub name: Cow<'a, str>,
/// The player UUID.
pub id: Uuid,
}
/// A minimal `Config` implementation for testing purposes.
#[cfg(test)]
pub(crate) struct MockConfig<S = (), Cl = (), E = (), W = (), Ch = (), P = ()> {
_marker: std::marker::PhantomData<(S, Cl, E, W, Ch, P)>,
}
#[cfg(test)]
impl<S, Cl, E, W, Ch, P> Config for MockConfig<S, Cl, E, W, Ch, P>
where
S: Send + Sync + 'static,
Cl: Default + Send + Sync + 'static,
E: Send + Sync + 'static,
W: Send + Sync + 'static,
Ch: Send + Sync + 'static,
P: Send + Sync + 'static,
{
type ServerState = S;
type ClientState = Cl;
type EntityState = E;
type WorldState = W;
type ChunkState = Ch;
type PlayerListState = P;
}