drewridley / nevy Goto Github PK

In Nevy, it will be essential that developers are able to specify custom logic to determine how, when and if a given component change should be synchronized. This tracking issue will contain discussions, possible designs, and the implications of such designs.

Requirements:

• Limited fragmentation of messages
• Ability to defer/expire messages
• O(n) complexity or better. Should integrate with queries to reduce total search space and complexity
• Eventually consistent, ie, changes not streamed should still eventually exist on the client for state that needs to be synchronzied.
• Datastructure agnostic; Nevy should not enforce a particular acceleration structure or mapping for this 'predicated' streaming.
• Entity driven; Messages or events should be optionally entity directed and the predicated logic can be associated with that entity.

The WebTransport implementation is tightly coupled to Bevy in update_endpoints. I'm interested in using this library to replace the renet2 WebTransport implementation, but need to use it in non-Bevy context. Can you wrap the APIs in an abstraction layer (e.g. higher-level resource)?

Currently, this crate does not expose ways to validate connections while they are being set up. Aggressive validation is needed to avoid attack vectors that consume server resources (e.g. opening many zombie connections).

In renet2 I have two primary validation steps:

• Server capacity: After Endpoint::accept, I immediately check if there is server capacity. At this point very little has been invested in the connection, so the effects of connection spam are minimized.
• WebTransport connection request: If there is capacity, I validate the WebTransport connection request. This involves extracting a netcode connection request from the WebTransport URI and waiting for that request to be validated before finalizing the connection. The request is directly embedded in the URI so I can immediately validate the request without needing to put the pending client on a timer or devote additional resources to the connection (e.g. a tokio task is needed for the stream reader), and to minimize connect times.

Also:

• WebTransportEndpoint should have a getter for the underlying SocketAddr. That address needs to be sent to clients so they know where to connect.