naia-lib / naia Goto Github PK

a cross-platform (including Wasm!) networking library built in Rust. Intended to make multiplayer game development dead-simple & lightning-fast

License: Apache License 2.0

Rust 99.29% JavaScript 0.71%

naia's People

Stargazers

Watchers

naia's Issues

Server uses ~100% of CPU

This is a flaw of the polling strategy used by the Server:

Async code runs in separate threads, waiting for messages coming from clients
Sync code tries to pull messages from a shared channel, but it does this in a loop

So currently in the sync code, if there are no messages found in the shared message channel, will just loop back and check again, again, again, until there is a message. This constant checking uses near 100% of CPU.

How does one fix this? One solution would be to remove the Sync code ... unfortunately, this would break the Bevy adapter.
The other solution might be to constantly measure time between new incoming messages, and then at the average measured duration. This makes the Server potentially less responsive, but it will poll less frequently.

I need to learn what strategies have been used in the past to overcome this - it's a common, old problem for Servers. If anyone has any ideas or any learning resources .. please let me know!

Allow disabling WebRTC support / Split HTTP(S) into an optional Cargo `feature`

It appears that webrtc-unreliable-client is not currently configurable as optional, and it adds quite a bit of overhead for native-only / non-WASM applications. Even if this is only for development purposes, reduced code-size by dropping WASM-aimed functionality can help with iteration time when working with something like Bevy.

Doc builds for naia-bevy-server are failing

See https://docs.rs/crate/naia-bevy-server/latest

naia-shared-0.12.1 build fails "cannot find attribute `derive_channels` in this scope"

To reproduce, create a new cargo project and add the dependency naia-shared = "0.12.1", then build.

This also breaks the other crates because of the dependency. e.g. naia-bevy-client = "0.12.0" has the same error.

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.65.0-nightly (2e35f954a 2022-09-01)

error: cannot find attribute `derive_channels` in this scope
  --> /home/gak/.cargo/registry/src/github.com-1ecc6299db9ec823/naia-shared-0.12.1/src/shared_config.rs:54:3
   |
54 | #[derive_channels]
   |   ^^^^^^^^^^^^^^^
   |
   = note: consider importing one of these items:
           crate::derive_channels
           naia_derive::derive_channels

error[E0433]: failed to resolve: use of undeclared type `ChannelDirection`
  --> /home/gak/.cargo/registry/src/github.com-1ecc6299db9ec823/naia-shared-0.12.1/src/shared_config.rs:63:20
   |
63 |         direction: ChannelDirection::ClientToServer,
   |                    ^^^^^^^^^^^^^^^^ use of undeclared type `ChannelDirection`

There are a few other errors after these.

closing server sockets

It doesn't appear that there's a way to shutdown or stop listening to a port once it's started? The server API has listen, but no way to close. Dropping the server resource doesn't seem to release the socket/port. What's the expected way to shutdown a bevy server resource?

Bevy 0.9 support

Love this project!

Are there plans in the works for upgrading naia to Bevy 0.9 yet?

Empty packet crashes Server

From AbleTheAbove in Naia's Discord (07/19/2022)

I run the server and connect to the server with netcat in udp mode pointing to 14191 (default addr) and send an empty message which causes the server to panic

I think maybe this function should return a Result to avoid people crashing the server with an empty packet

// In shared/serde/src/reader_writer.rs:133:17
    pub(crate) fn read_bit(&mut self) -> bool {
        if self.state.scratch_index == 0 {
            if self.state.buffer_index == self.buffer.len() {
                panic!("no more bytes to read");
            }

The examples fail with "send failed! [...] AddrNotAvailable [...]"

When running the examples with

cd demo/server
cargo run --features "use-udp"

And

cd demo/client
cargo run --bin naia-client-miniquad-example

The client panics with the message

thread 'main' panicked at 'send failed!: Os { code: 10049, kind: AddrNotAvailable, message: "The requested address is not valid in its context." }', C:\Source\naia\client\src\naia_client.rs:456:14

I'm on Windows 10 and it's failing with the exact same panic in my own demo implementation. What's going wrong?

Implementation of InterpLerpable for floating point types

Why is there no implementation of InterpLerpable for other types than u16 (e.g. f32 or f64)?

Bevy - Example code panics on rejection.

pub fn reject_event(client: Client<Protocol, Channels>) {
    info!(
        "Client rejected from connecting to: {}",
        client.server_address()
    );
}

The call to client.sever_address() panics because the connection has already closed.

thread 'main' panicked at 'Cannot call Client.server_addr_unwrapped() until you call Client.connect()!',

I would suggest not panicing here at all, but pushing up a result indicating success or failure.

When the bevy client requests a disconnect, the bevy server does not emit a disconnection event

Instead, the client disconnects silently. With the default settings, the server will finally emit the event after 30 seconds of inactivity.

After some debugging, it turns out the verify_disconnect_request function always returns false under this case.

naia/server/src/server.rs

Lines 945 to 947 in a8372c6

 if self 

 .handshake_manager 

 .verify_disconnect_request(user_connection, &mut reader)

It looks like this might be a more general problem than only the bevy client.

I don't understand the verification part, does anyone have a better clue of what's going on?

Native WebRTC client sockets

It's been a long goal for naia-socket-server to support connections to both Web & Native clients at the same time..

It seems the best way to get there now is via an implementation using https://github.com/webrtc-rs, and I've created an example repo to test out connectivity between webrtc-rs and naia-server-socket here: https://github.com/naia-lib/naia-socket-webrtc-rs-example. (Thank you @billyb2 for taking a first stab at this! I used some of your code.)

Currently we're hung up on DTLS handshake ... I suspect there's a version mismatch.

webrtc-rs main issue: webrtc-rs/webrtc#163
webrtc-rs/dtls issue: webrtc-rs/dtls#15

Nightly release required?

Hello, I was trying out the demo code, and I got the following compile error:

cargo run --features "use-webrtc"
   Compiling naia-server-socket v0.7.0
   Compiling naia-basic-demo-shared v0.1.0 (/home/apridgen/Documents/rust_game_dev/naia/demos/basic/shared)
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> demos/basic/shared/src/lib.rs:1:12
  |
1 | #![feature(const_type_id)]
  |            ^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `naia-basic-demo-shared` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

I am not a good rust software developer, so here goes a dumb question. Do I need to be using nightly (unstable) release to use this framework?

Thanks for putting this project together nonetheless.

Shared LinkConditionerConfig

Does LinkConditionerConfig belong to SharedConfig?

As I understand SharedConfig is a set of configuration that absolutely needs to be in sync between server and client in order for the network communication to work properly.

Link condition does not belong to this category. Usually this is the other way - server and client have really different network link reliability. It should be possible to configure different link condition in NaiaServer and NaiaClient.

Building at workspace root does not compile

Might be worth adding a toolchain file

On nightly:

cargo build --features use-udp
...
   Compiling crossbeam-channel v0.4.4
error: no rules expected the token `aarch64_apple`
   --> /home/rishflab/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/src/cpu.rs:257:13
    |
165 |     macro_rules! features {
    |     --------------------- when calling this macro
...
257 |             aarch64_apple: true,
    |             ^^^^^^^^^^^^^ no rules expected this token in macro call

error[E0425]: cannot find value `AES` in module `cpu::arm`
   --> /home/rishflab/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/src/aead/aes.rs:381:65
    |
381 |         if cpu::intel::AES.available(cpu_features) || cpu::arm::AES.available(cpu_features) {
    |                                                                 ^^^ not found in `cpu::arm`
    |
help: consider importing this constant
    |
15  | use crate::cpu::intel::AES;
    |

error[E0425]: cannot find value `PMULL` in module `cpu::arm`
   --> /home/rishflab/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/src/aead/gcm.rs:315:26
    |
315 |             || cpu::arm::PMULL.available(cpu_features)
    |                          ^^^^^ not found in `cpu::arm`

error[E0425]: cannot find value `ARMCAP_STATIC` in this scope
   --> /home/rishflab/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/src/cpu.rs:235:41
    |
235 |             if self.mask == self.mask & ARMCAP_STATIC {
    |                                         ^^^^^^^^^^^^^ not found in this scope

   Compiling fontdue v0.3.2
   Compiling regex v1.5.4
   Compiling flate2 v1.0.22
   Compiling idna v0.2.3
   Compiling async-executor v1.4.1
For more information about this error, try `rustc --explain E0425`.
error: could not compile `ring` due to 4 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed

On stable:

 cargo build --features use-udp
    Updating crates.io index
  Downloaded bevy v0.6.0
  Downloaded bevy_ecs v0.6.0
  Downloaded 2 crates (295.5 KB) in 1.56s
warning: output filename collision.
The bin target `index` in package `naia-hecs-client-demo v0.1.0 (/home/rishflab/naia-rs/naia/demos/hecs/client)` has the same output filename as the bin target `index` in package `naia-basic-client-demo-wb v0.1.0 (/home/rishflab/naia-rs/naia/demos/basic/client/wasm_bindgen)`.
Colliding filename is: /home/rishflab/naia-rs/naia/target/debug/index
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The bin target `index` in package `naia-tickless-client-demo v0.1.0 (/home/rishflab/naia-rs/naia/demos/tickless/client)` has the same output filename as the bin target `index` in package `naia-hecs-client-demo v0.1.0 (/home/rishflab/naia-rs/naia/demos/hecs/client)`.
Colliding filename is: /home/rishflab/naia-rs/naia/target/debug/index
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
   Compiling bevy_ecs v0.6.0
   Compiling bevy_app v0.6.0
   Compiling bevy_log v0.6.0
   Compiling bevy_core v0.6.0
   Compiling bevy_transform v0.6.0
   Compiling bevy_window v0.6.0
   Compiling bevy_input v0.6.0
   Compiling bevy_diagnostic v0.6.0
   Compiling bevy_winit v0.6.1
   Compiling bevy_asset v0.6.0
   Compiling bevy_render v0.6.1
   Compiling bevy_scene v0.6.0
   Compiling bevy_core_pipeline v0.6.0
   Compiling bevy_sprite v0.6.0
   Compiling bevy_pbr v0.6.1
   Compiling bevy_gltf v0.6.0
   Compiling bevy_text v0.6.0
   Compiling bevy_ui v0.6.1
   Compiling bevy_internal v0.6.0
   Compiling bevy v0.6.0
   Compiling naia-shared v0.8.0 (/home/rishflab/naia-rs/naia/shared)
   Compiling naia-client v0.8.0 (/home/rishflab/naia-rs/naia/client)
   Compiling naia-demo-world v0.1.0 (/home/rishflab/naia-rs/naia/demos/demo_utils/demo_world)
   Compiling naia-server v0.8.0 (/home/rishflab/naia-rs/naia/server)
   Compiling naia-hecs-shared v0.8.0 (/home/rishflab/naia-rs/naia/adapters/hecs/shared)
   Compiling naia-basic-demo-shared v0.1.0 (/home/rishflab/naia-rs/naia/demos/basic/shared)
   Compiling naia-bevy-shared v0.9.0 (/home/rishflab/naia-rs/naia/adapters/bevy/shared)
   Compiling naia-empty-world v0.1.0 (/home/rishflab/naia-rs/naia/demos/demo_utils/empty_world)
   Compiling naia-tickless-demo-shared v0.1.0 (/home/rishflab/naia-rs/naia/demos/tickless/shared)
   Compiling naia-hecs-demo-shared v0.1.0 (/home/rishflab/naia-rs/naia/demos/hecs/shared)
   Compiling naia-macroquad-demo-shared v0.1.0 (/home/rishflab/naia-rs/naia/demos/macroquad/shared)
   Compiling naia-bevy-demo-shared v0.1.0 (/home/rishflab/naia-rs/naia/demos/bevy/shared)
error[E0277]: the trait bound `Auth: bevy_ecs::component::Component` is not satisfied
  --> demos/macroquad/shared/src/protocol/auth.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Auth`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Auth: bevy_ecs::component::Component` is not satisfied
  --> demos/macroquad/shared/src/protocol/auth.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Auth`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `KeyCommand: bevy_ecs::component::Component` is not satisfied
  --> demos/macroquad/shared/src/protocol/key_command.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `KeyCommand`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `KeyCommand: bevy_ecs::component::Component` is not satisfied
  --> demos/macroquad/shared/src/protocol/key_command.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `KeyCommand`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Square: bevy_ecs::component::Component` is not satisfied
  --> demos/macroquad/shared/src/protocol/square.rs:19:10
   |
19 | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Square`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Auth: bevy_ecs::component::Component` is not satisfied
  --> demos/hecs/shared/src/protocol/auth.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Auth`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Square: bevy_ecs::component::Component` is not satisfied
  --> demos/macroquad/shared/src/protocol/square.rs:19:10
   |
19 | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Square`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Auth: bevy_ecs::component::Component` is not satisfied
  --> demos/hecs/shared/src/protocol/auth.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Auth`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Marker: bevy_ecs::component::Component` is not satisfied
  --> demos/hecs/shared/src/protocol/marker.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Marker`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
error[E0277]: the trait bound `Marker: bevy_ecs::component::Component` is not satisfied
  --> demos/hecs/shared/src/protocol/marker.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Marker`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `naia-macroquad-demo-shared` due to 6 previous errors
warning: build failed, waiting for other jobs to finish...
error[E0277]: the trait bound `Name: bevy_ecs::component::Component` is not satisfied
  --> demos/hecs/shared/src/protocol/name.rs:13:10
   |
13 | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Name`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Name: bevy_ecs::component::Component` is not satisfied
  --> demos/hecs/shared/src/protocol/name.rs:13:10
   |
13 | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Name`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Position: bevy_ecs::component::Component` is not satisfied
  --> demos/hecs/shared/src/protocol/position.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Position`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Position: bevy_ecs::component::Component` is not satisfied
  --> demos/hecs/shared/src/protocol/position.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Position`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Text: bevy_ecs::component::Component` is not satisfied
  --> demos/tickless/shared/src/text.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Text`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Text: bevy_ecs::component::Component` is not satisfied
  --> demos/tickless/shared/src/text.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Text`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Auth: bevy_ecs::component::Component` is not satisfied
  --> demos/basic/shared/src/protocol/auth.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Auth`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Auth: bevy_ecs::component::Component` is not satisfied
  --> demos/basic/shared/src/protocol/auth.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Auth`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Character: bevy_ecs::component::Component` is not satisfied
  --> demos/basic/shared/src/protocol/character.rs:13:10
   |
13 | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Character`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Character: bevy_ecs::component::Component` is not satisfied
  --> demos/basic/shared/src/protocol/character.rs:13:10
   |
13 | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `Character`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `StringMessage: bevy_ecs::component::Component` is not satisfied
  --> demos/basic/shared/src/protocol/string_message.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `StringMessage`
   |
note: required by a bound in `ReplicateSafe`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:19:43
   |
19 | pub trait ReplicateSafe<P: ProtocolType>: ReplicateInner {
   |                                           ^^^^^^^^^^^^^^ required by this bound in `ReplicateSafe`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `StringMessage: bevy_ecs::component::Component` is not satisfied
  --> demos/basic/shared/src/protocol/string_message.rs:4:10
   |
4  | #[derive(Replicate)]
   |          ^^^^^^^^^ the trait `bevy_ecs::component::Component` is not implemented for `StringMessage`
   |
note: required by a bound in `Replicate`
  --> /home/rishflab/naia-rs/naia/shared/src/replicate.rs:13:39
   |
13 | pub trait Replicate<P: ProtocolType>: ReplicateSafe<P> {
   |                                       ^^^^^^^^^^^^^^^^ required by this bound in `Replicate`
   = note: this error originates in the derive macro `Replicate` (in Nightly builds, run with -Z macro-backtrace for more info)

error: build failed

Bevy Demo - Wasm version is very slow

This is a strange one, I've got to look into it further. This is not fixed by running in release mode

Doc strings don't work on enum variants with `derive_serde` macro

I've run into an issue where I can't add doc strings to enum variants that will use derive_serde.

#[derive_serde]
pub enum Building {
    /// Able to construct different items. The workshop should be a building
    /// that all players either start with or want to invest in on their first
    /// few turns.
    Workshop,
    /// The production mill can mine various different resources. There should
    /// be some generic resources that we're familiar with, then some scifi
    /// resources.
    ProductionMill,
    /// The pub allows players to recruit new mercenaries for various missions.
    Pub,
}

The error that comes up is

custom attribute panicked
message: Unnamed variants are not supported

This makes sense, since digging into the parser shows:

let variant_name = next_ident(&mut body).expect("Unnamed variants are not supported");

where next_ident presumably returns none on anything that's not an ident:

pub fn next_ident(source: &mut Peekable<impl Iterator<Item = TokenTree>>) -> Option<String> {
    if let Some(TokenTree::Ident(ident)) = source.peek() {
        let ident = format!("{}", ident);
        source.next();
        Some(ident)
    } else {
        None
    }
}

Separate the message-passing from the ECS-replication parts of naia.

Currently, messages need to be part of the Protocol enum. This means that they:

need to implement Replicate
their fields have to be Property or EntityProperty
they need to derive Bevy's Component

All of these shouldn't be needed

derive(Event) uses hardcoded ExampleEvent name

https://github.com/naia-rs/naia/blob/c68245ef62f39e27a0c60a251250606c5510fec8/derive/src/event.rs#L55

I would like to name my Events enum differently 😉 (i.e. NetworkEvent).

Bevy 0.8 Support

Hey there

Super excited to use with bevy 0.8!

Any plans to support?

Documentation link is broken

Hi,

Not sure if you are aware, but the documentation page is redirecting to some weird insecure site.

Current Games using Naia?

Was looking at this:
https://www.reddit.com/r/rust/comments/hj2eey/naia_a_crossplatform_networking_library_for/
By any chance does this "open-source 100+ player Battle Royale 2D web game" exist yet?

If not, was there any public games I could play around with using naia?

Windows: OS errors when negotiating...?

Windows 11

Code is just a simple connect to a local server:

client.auth(Auth::new("test", "12345"));
client.connect("http://192.168.1.190:14191");

I get these errors, but am not sure yet if they are a naia level issue (use of webrtc_unreliable) or an issue with webrtc_unreliable:

2022-09-23T14:34:57.903796Z  INFO webrtc_unreliable_client::webrtc::peer_connection: signaling state changed to have-local-offer    
2022-09-23T14:34:57.905683Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlled]: could not listen udp 26:17:f000:a060:eed9:3d7a:c3b3:194b: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.906316Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlled]: could not listen udp 169.254.129.206: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.906553Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlled]: could not listen udp 169.254.76.106: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.906798Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlled]: could not listen udp ::0.0.1.0: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.906951Z  INFO webrtc_unreliable_client::webrtc::peer_connection: signaling state changed to stable
2022-09-23T14:34:57.907084Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlled]: could not listen udp 80fe::eed9:3d7a:c3b3:194b: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.907184Z  INFO webrtc_unreliable_client::webrtc::crates::ice::agent::agent_internal: [controlling]: Setting new connection state: Checking
2022-09-23T14:34:57.907273Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlling]: could not listen udp 26:17:f000:a060::c00: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.907594Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlling]: could not listen udp 26:17:f000:a060:acc4:dfec:5cac:c75f: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.907830Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlling]: could not listen udp 80fe::d945:4b2e:d7cb:2289: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.908064Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlling]: could not listen udp 169.254.215.234: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.908473Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlling]: could not listen udp 80fe::43c9:d10c:e330:5acf: io error: The requested address is not valid in its context. (os error 10049)
2022-09-23T14:34:57.908717Z  WARN webrtc_unreliable_client::webrtc::crates::ice::agent::agent_gather: [controlling]: could not listen udp 169.254.145.112: io error: The requested address is not valid in its context. (os error 10049)

Clients disconnecting crashes the server

Currently the server side of the bevy implementation ( have not tested others ) crashes if the client is disconnected or forcefully terminated

Reproduce

start the bevy server demo
start a bevy client demo
see that they connect
terminate the bevy client demo ( ctrl+c )
wait a few seconds
server crashes

Message

2022-01-26T10:31:25.498048Z  INFO naia_bevy_server_demo::systems::events: Naia Server connected to: 192.168.0.148:47069
2022-01-26T10:31:25.892420Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:25.990874Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:26.192203Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:26.342943Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:26.486405Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:26.793078Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:27.346493Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:28.431269Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:29.191041Z  INFO naia_socket_shared::link_condition_logic: link conditioner: packet lost
2022-01-26T10:31:41.684753Z  INFO naia_bevy_server_demo::systems::events: Naia Server disconnected from: 192.168.0.148:47069
thread 'main' panicked at 'No User exists for given Key!', /home/krille/projects/naia/server/src/server.rs:375:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Firefox issues: won't connect to Public IP (but OK on LAN)

Hi,

I've been able to get a connection from Firefox to naia based server via WebRTC perfectly fine on LAN addresses. As soon as it connects via a public IP address, I get the error below. I can only guess it is using some other protocol when it should just be sending a HTTP POST?

I've tried many combinations of things with no luck. CORS is enabled for all hosts, if that makes a difference.

When changing the IP address I always update the public_webrtc_url in ServerAddrs to match the public IP address of the server.

I thought it was a firewall issue (at home), so I just ran it on a DigitalOcean host (which is what the logs are below) and exactly the same thing happened.

(Very limited knowledge about this:) I tried removing the STUN entries as I don't need any sort of NAT, as the server is not behind a NAT, but that caused a panic elsewhere in the code.

2022-08-24T21:24:27.803226Z  INFO server::init: Server running! http://198.199.92.237
2022-08-24T21:24:28.262014Z  INFO webrtc_unreliable::server: new WebRTC data channel server listening on 0.0.0.0:24192, public addr 198.199.92.237:24192
2022-08-24T21:24:28.262310Z  INFO naia_server_socket::backends::webrtc::session: Session initiator available at POST http://0.0.0.0:24191/rtc_session    
thread 'smol-1' panicked at 'called `Result::unwrap()` on an `Err` value: FromUtf8Error { bytes: [22, 3, 1, 2, 0, 1, 0, 1, 252, 3, 3, 178, 173, 225, 104, 22, 115, 221, 23, 221, 233, 244, 68, 156, 1, 103, 246, 93, 182, 97, 41, 46, 201, 60, 15, 209, 134, 47, 79, 52, 43, 22, 161, 32, 12, 185, 154, 2, 24, 139, 104, 127, 92, 69, 57, 125, 25, 26, 129, 119, 212, 138, 235, 20, 66, 11, 71, 86, 39, 173, 220, 43, 95, 138, 160, 65, 0, 34, 19, 1, 19, 3, 19, 2, 192, 43, 192, 47, 204, 169, 204, 168, 192, 44, 192, 48, 192], error: Utf8Error { valid_up_to: 8, error_len: Some(1) } }', /root/naia/socket/server/src/backends/webrtc/session.rs:101:63

Sorry for asking in here, this is probably me doing something stupid (I don't know much about WebRTC), and thought this would be the best place to get a good answer. Thanks for any hints/help.

Dealing with Entity Relations

Context

I am having issues handling relations between entities properly.
As an example; I have a 'Head' entity and a 'Segment' entity.
In the segment entity, I want to add a HasHead(EntityProperty) component that contains the head's entity.

If I just use naia's replication channel, i often get panics because the HasHead component gets sent to the server before the client has spawned the corresponding Head entity. The client cannot read the net_entity_id corresponding to the Head because it doesn't exist, and Naia panics.

Potential solutions

Naia has a mechanism where it waits for confirmation that the client has spawned the entity before sending the corresponding EntityProperty. This seems to work for messages, but not for components that get automatically replicated.
- also, it's not ideal, because this adds a certain amount of latency before the HasHead component gets replicated between client and server
Add some kind of ordering system, where I can replicate a group of components from client to server, and the client will handle them in the same order?
Pre-reserve a set of entities on client/server so that we avoid panics when an net_entity doesn't match an entity in the Bevy world?
See how other networking libraries handle this issue

Firefox issues: Wasm client socket doesn't connect

Here is an example message when attempting to run the demo on the Firefox browser

STUN-CLIENT(zcVq|IP4:192.168.1.100:42831/UDP|IP4:172.104.138.54:55501/UDP(host(IP4:192.168.1.100:42831/UDP)|candidate:1 1 UDP 4006861156 172.104.138.54 55501 typ host)): Received response; processing

STUN-CLIENT(zcVq|IP4:192.168.1.100:42831/UDP|IP4:172.104.138.54:55501/UDP(host(IP4:192.168.1.100:42831/UDP)|candidate:1 1 UDP 4006861156 172.104.138.54 55501 typ host)): XOR-MAPPED-ADDRESS is bogus

STUN-CLIENT(zcVq|IP4:192.168.1.100:42831/UDP|IP4:172.104.138.54:55501/UDP(host(IP4:192.168.1.100:42831/UDP)|candidate:1 1 UDP 4006861156 172.104.138.54 55501 typ host)): Error processing response: Invalid data, stun error code 0.

Should log an issue with https://github.com/kyren/webrtc-unreliable to troubleshoot this. The readme there says that Firefox WebRTC connections don't work when using a loopback address, but it's actually breaking in production.

naia-basic-server-demo cannot be run

When a client connects, I get this:

2022-01-08 19:30:34,210 INFO [naia_basic_server_demo::app] Basic Naia Server Demo started thread 'main' panicked at 'Could not determine the UTC offset on this system. Possible causes are that the time crate does not implement "local_offset_at" on your system, or that you are running in a multi-threaded environment and the time crate is returning "None" from "local_offset_at" to avoid unsafe behaviour. See the time crate's documentation for more information. (https://time-rs.github.io/internal-api/time/index.html#feature-flags): IndeterminateOffset', /home/nyvs/.cargo/registry/src/github.com-1ecc6299db9ec823/simple_logger-1.16.0/src/lib.rs:409:85 note: run with RUST_BACKTRACE=1environment variable to display a backtrace

Using arch linux,

Thank you for your help

Tickless Client & Server?

This shared config: https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/shared/src/shared_config.rs#L8 should be changed to Option<Duration>, and accept a None value.

If there is a tick_interval of None, then the Server should have no need for this:
https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L221

, and neither the Client or Server should return Tick events

This will make it more performant to have multiple Clients or Servers on a single host. Also, the "tick" concept may not apply to all types of games.

WebRTC demo client crashes with "Already Borrowed: BorrowMutError" when it can't connect to the server

as noted by @Oberdiah in: https://github.com/naia-rs/naia-socket/issues/58

It's probably worth demonstrating how to handle this more gracefully in the demo, as it's something that all naia-socket applications will have to handle.

panicked at 'already borrowed: BorrowMutError', naia-client-socket-0.9.0\src\impls\wasm_bindgen\packet_sender.rs:45:70

Server continues to try to pair with rejected client?

If we force an auth failure, the server will continue to send heartbeats to the client for some time. The client doesn't know what to do with these:

2022-09-23T14:52:23.130602Z  INFO webrtc_unreliable_client::webrtc::peer_connection: ICE connection state changed: connected    
2022-09-23T14:52:23.132988Z  INFO webrtc_unreliable_client::webrtc::peer_connection: peer connection state changed: connected
2022-09-23T14:52:24.087938Z  INFO jernau::networking::client::events: Client was rejected!
2022-09-23T14:52:27.733648Z  WARN webrtc_unreliable_client::webrtc::crates::sctp::association::association_internal: [] unable to parse SCTP packet heartbeat should only have HEARTBEAT param
[ repeat this heartbeat warn on client until the server closes the connection ]

After a bit, the server times out the connection, but then tries to begin a new channel connection. This doesn't work because the client is no longer engaged:

2022-09-23T14:52:23.132703Z  INFO webrtc_unreliable::client: DTLS handshake finished for remote 192.168.1.190:64607
2022-09-23T14:52:23.887893Z  INFO jernau::networking::server::events: auth event!
2022-09-23T14:52:23.888111Z  INFO jernau::networking::server::events: rejected!
2022-09-23T14:52:24.136325Z  INFO jernau::networking::server::events: auth event!
2022-09-23T14:52:24.136591Z  INFO jernau::networking::server::events: rejected!
[ heart beats are still sent here ]
2022-09-23T14:53:00.981007Z  INFO webrtc_unreliable::server: connection timeout for client 192.168.1.190:64607
2022-09-23T14:53:00.981312Z  INFO webrtc_unreliable::server: client 192.168.1.190:64607 removed
2022-09-23T14:53:02.717221Z  INFO webrtc_unreliable::server: beginning client data channel connection with 192.168.1.190:64607
2022-09-23T14:53:41.281051Z  INFO webrtc_unreliable::server: connection timeout for client 192.168.1.190:64607
2022-09-23T14:53:41.281332Z  INFO webrtc_unreliable::server: client 192.168.1.190:64607 removed
2022-09-23T14:53:43.203230Z  INFO webrtc_unreliable::server: beginning client data channel connection with 192.168.1.190:64607

I would expect that a rejection would close to the connection, not send heartbeats, and not attempt to renegotiate with a rejected client.

Client.connect panics if connection is refused

What happens

If you connect to an address that doesn't have a server running, the client panics when calling client.connect.

thread 'main' panicked at 'Could not send request, original error: reqwest::Error { kind: Request, url: Url { scheme: "http", cannot_be_a_base: false, username: "", password: None, host: Some(Ipv4(127.0.0.1)), port: Some(14191), path: "/rtc_session", query: None, fragment: None }, source: hyper::Error(Connect, ConnectError("tcp connect error", Os { code: 10061, kind: ConnectionRefused, message: "No connection could be made because the target machine actively refused it." })) }', C:\Users\Paul\.cargo\registry\src\github.com-1ecc6299db9ec823\webrtc-unreliable-client-0.1.2\src\socket.rs:109:17

This can be seen by running any of the client examples without a server running.

What I would like to happen

It would be nice if client.connect returned a result with different errors (Usually an enum) for the different failure states, allowing me to show an error message to users and allow them to retry without leaving my app.

naia_shared depends on bevy_ecs

bevy_ecs appears in the naia-shared crate while it should only appear in the bevy adaptor crates?

Make resilient to DDOS attack

Could someone, given a public IP address of a NaiaServer, and clever usage of this open-source code (a modified or unmodified NaiaClient) DDOS our server? How can we protect against this?

I'm definitely looking for advice / input here, so if you've got any, please tell me.

Possibly Useful Additions:

On a per-IP-address basis, allow some "suspicion" value to be accumulated for suspicious behavior. "suspicion" degrades slowly over time, but after some max level, terminates the connection. Every time the IP-address attempts to re-establish the connection thereafter, "suspicion" is raised.

If the IP-address "suspicion" levels are sufficiently high, blacklist the IP. The IP may only be allowed to re-connect once "suspicion" levels have degraded to some necessary minimum (unless placed on the blacklist). We may require some ability to clear a Server's blacklist manually ?

https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L236 at this point is useful, to refresh the connection with the client, but we should be checking whether there has been an established connection AFTER reading the packet_type from the StandardHeader.

This would allow us to detect when a client is sending packets of a type that typically precedes Connection establishment. Some of this is expected, but too many packets, especially after a long duration, should raise "suspicion" levels.

At this point: https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L288 we are receiving ClientConnectRequest packets AFTER the Connection has been established ... this should raise "suspicion" levels.
Non-matching Challenge Timestamps should raise "suspicion" levels. https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L303
Invalid ServerDigest should raise "suspicion" levels: https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L326
Unsuccessful Auth attempts should raise "suspicion" levels: https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L341
Pings, Data, and Heartbeat packets from un-authed clients should raise "suspicion" levels: https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L386, https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L406, https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L441
Invalid PacketType from StandardHeader should raise "suspicion" levels: https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L449
Errors should raise "suspicion" levels: https://github.com/naia-rs/naia/blob/984673ebe65b0f38e76973f56081d8b9e53bc7c0/server/src/naia_server.rs#L453

Bevy's server adapter documentation displays wrong `Server`

The naia-bevy-server documentation seems to be displaying two links for the Server struct which both seem to point to the naia-server Server documentation

This seems to be caused by importing the entire naia-server

naia/adapters/bevy/server/src/lib.rs

Line 1 in 6ed1a35

pub use naia_server::*;

And the Server

naia/adapters/bevy/server/src/lib.rs

Line 15 in 6ed1a35

pub use server::Server;

This could be fixed by:

Importing only the necessary items from naia-server
Importing naia-server as a namespace (instead of it's items)
Renaming the naia-bevy-server Server to something else

Client should be able to request a Disconnect

Currently the Client has no way to trigger a manual disconnect from the Server .. The Server just times out the connection if the Client app / window is closed. There should be some client.disconnect() function to do this clientside.

Allow re-auth

Hey there, I've got a suggestion for auth: It would be helpful to be able to re-auth at any point, in the case where the user's session is going to expire while the user is connected.

Integration with entity-component systems

This is more of an open-ended question than an issue, so feel free to close.

Entity-component systems are quite common in games, and in particular in the Rust world. I'm wondering if there's a natural way to use an ECS like Specs or Legion and synchronize entities and components over the wire. Have you thought about this?

Perhaps this is something that could be implemented as a third-party library living on top of Naia, using Naia entities to sync ECS state in a clever way.

Panic when despawning entities

When despawning an entity through the naia bevy server and EntityMut it crashes. This is due to it trying to get all the entities components in EntityManager but the entity is not found in the WorldRecord resulting in it panicking with, 'entity does not exist!'.

To reproduce this bug run the naia bevy demo and open up two clients. When both clients have connected, close one of the clients down and then when the connection times out, it will try to remove the entity and eventually crash.

bevy client demo cannot be run

When I try to run the demo with either nightly or stable, it fails on startup:

Compiling naia-bevy-client-demo v0.1.0 (/run/media/nyvs/Data/Projects/naia/demos/bevy/client) Finished release [optimized] target(s) in 43.69s Running /run/media/nyvs/Data/Projects/naia/target/release/naia-bevy-client-demoJan 08 19:22:53.030 INFO naia_bevy_client_demo::systems::init: Naia Bevy Client Demo started thread 'main' panicked at 'Requested resource does not exist: alloc::boxed::Box<dyn bevy_render::renderer::render_resource_context::RenderResourceContext>', thread '/home/nyvs/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/system_param.rsthread 'Compute Task Pool (11):Compute Task Pool (15)' panicked at '244' panicked at 'Requested resource does not exist: alloc::boxed::Box<dyn bevy_render::renderer::render_resource_context::RenderResourceContext>:Requested resource does not exist: alloc::boxed::Box<dyn bevy_render::renderer::render_resource_context::RenderResourceContext>', 17', /home/nyvs/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/system_param.rs /home/nyvs/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/system_param.rs:note: run withRUST_BACKTRACE=1environment variable to display a backtrace :244244::1717

Future feature plans

Hey,
I'm just opening this to keep track of the future features we talked about. Feel free to close if you track them somewhere else! :)

separate the message-passing from the ECS-replication parts of naia.
being able to pass any struct as a message (separte change-detection Property/Replicate from serialiazation (which shouldn't need to derive Property/Replicate))
being able to have different tick-frequencies (i.e. network send) per message/component. Being able to send messages separately from ECS-components.
being able to split the Protocolize enum into multiple pieces

WebRTC's `serve` may panic if a connection is reset before reading the stream

As noted by @mvlabat in https://github.com/naia-rs/naia-socket/issues/33

I've recently stumbled upon the following panic in my application:

thread 'smol-1' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }', /home/ubuntu/.cargo/git/checkouts/naia-socket-333addd872c4cece/b7d679b/server/src/impls/webrtc/session.rs:65:33

I believe it happens because a connection is reset before a server can actually finish reading the stream. I think that we can catch that error and just return immediately since we won't be able to respond.

https://github.com/naia-rs/naia-socket/blob/fe37421fadea23b7e1ef3aeec07c8bb3cac5a55f/server/src/impls/webrtc/session.rs#L65

On a side note, naia-socket has quite a lot of uses of unwrap. I think we should take some effort to introduce better error handling, as things might still panic in other places unexpectedly. If unwrap is intentional, we should document why (by using expect, for example).

Running on 127.0.0.1 breaks Windows support

As per @smokku in https://github.com/naia-rs/naia-socket/issues/24

Change bd5365c breaks Windows support.

    Finished dev [unoptimized + debuginfo] target(s) in 0.84s
     Running `D:\devel\naia-socket\target\debug\naia-client-socket-miniquad-example.exe`
Naia Client Socket Example Started
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 10049, kind: AddrNotAvailable, message: "Żądany adres jest nieprawidłowy w tym kontekście." }', demo\client\miniquad\src\app.rs:39:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `D:\devel\naia-socket\target\debug\naia-client-socket-miniquad-example.exe` (exit code: 101)

Sending files and large packets

I need to be able to send Bevy scenes, GLTFs, WASM bins, Rhai scripts, and H.264 packets from my server to my client, all of which tend to be larger than the 508 byte limit on naia messages. Is there any way to do this from within naia?

If yes:

How can it be done, and can I add an example to the demos?

If no:

Is there a workaround or hack for getting naia to do it anyway?
What is your recommendation for how to do it without naia?
Is it a planned feature? What needs to be done to support it?

Thank you for making this fantastic set of libraries! Please let me know if there's anything I can do to help!

Flesh out deployment story for naia-socket.js

As observed by johnpmayer:

We need some basic instructions for how to go about making a change to the miniquad client's naia-socket.js file, and then deploying that out to https://github.com/naia-rs/naia-rs.github.io for public consumption

Production builds should not include LinkConditionerConfig

Conditionally compile LinkConditionerConfig so that no conditioning is enabled for release builds

`candidate_to_addr` in `wasm_utils` does not detect IPv6 address

As noted by @FF-AntiK in https://github.com/naia-rs/naia-socket/issues/57:

url_to_socket_addr returns the first address it can find, which could be IPv6:
https://github.com/naia-rs/naia-socket/blob/main/shared/src/url_parse.rs#L43

but the regex in candidate_to_addr does not support IPv6 ([::] notation):
https://github.com/naia-rs/naia-socket/blob/main/client/src/wasm_utils.rs#L9

Client should emit an AuthFailed event

If a Client fails to Auth, it currently will just keep trying to connect to the Server with the same Auth payload ... forever ...

Instead, the Server should repeatedly send back an "AuthFailed" message to the Client, and the Client should stop the handshaking process until you call Client.connect() again (hopefully with a new and working Auth payload)

Cannot fragment Replicate structs larger than 508 bytes

Hi, I love the asset and it has been working pretty well so far! It is very impressive.

I have found an issue with large packets, webrtc-unreliable lists a max size of ~1200 bytes which is what is used so I would assume my ~600 byte packet should work. This is reproducible in the bevy example by changing entity_assignment in the shared crate to contain my large amount of data.

#[protocol_path = "crate::protocol::Protocol"]
pub struct EntityAssignment {
    pub entity: EntityProperty,
    pub assign: Property<bool>,
    pub data: Property<[[[u8; 8]; 8]; 8]>
}

impl EntityAssignment {
    pub fn new(assign: bool) -> Self {
        EntityAssignment::new_complete(assign, [[[0; 8]; 8]; 8])
    }
}

The next time send_all_updates runs it will not return.