A proposal for basic networking abtractions for bevy: an RFC

[TirushOne]

Goals

I propose a automated system for network io that is intended to make it easier for bevy uses to create apps that utalise the power networking for any application they desire. I am also inviting any criticism or suggestions, as I want this system to be the best it can. This main goals of this system are:

• Make it easy and idomatic to network in bevy though the addition of a plugin that manages and holds ownership of networking primitives from std, TcpStream, UdpStream, and possibly TcpListener.
• Keep the user contact with std::io::Error to minimum, as it can be confusing to parse and can be handled automaticley in most cases.
• Keep unnerssery memory useage and copying to a minimum.
• Have a public facing api that does not make any sys-calls.
• The system should be efficiant on cpu time, this means using an async backend with non-blocking async reads and writes.
• The system should be as robust as possible, and any errors or issues that occur on the frontend should be easy to parse and understand for the user.
• The system should be scalable and able to handle many connections efficiently.

A system that meets the goals listed above could be a asset for networking in and of itself, however it could also serve as the basis for higher level networking abtractions in the future, such as a server-client replication system.

Design

The design is based on spin locks and global variables, with a emphasis on on ease of use and flexibility.

The idea is to have a type which buffers both incoming and outgoing data from and to the socket, with the actual interaction with the OS being handled by a par of system running each frame.

For eample adding a new socket might look like:

`let stream = TcpStream::new();

//the socket manager is a global variable that can
//be accessed from anywhere.
let manager = SocketManager::get();

//we pass in our TcpStream and get back access to an object which contains the
//incoming data obtained from the os, and any data we write to it
//will later to writen to the os in balk by the backend.
//This isolates any potential errors from the user and we only need
//pass back those errors for which there is no obvious cause of action
//and log the rest. This also means read/writing to this object
//does involve any async or blocking code,
//or any sys-calls.
let buffered = manager.register_tcp_stream(stream);`

In this design there would be a system that runs near the start of every frame that reads from the OS and populates the user-side
buffers with fresh data, and one near the end of each frame that writes data from the user side to the OS sockets. Data access are syncronised between the user and the backend by a spinlock.

Open Questions

What will be the allowed socket types?

I want the backend to be able to run asynchronously, but that means non-blocking async funtions that can read and write from TcpStream, and UdpSocket. async-net already provides async TcpStream, UdpSocket, and TcpListener types, which is quite conviniant, but they have to be constructed asynchronously and don't provide and method to convert their std equivalents into themselves. Which means the user has to use async code to interact with this system which isn't ideal, although there are work arounds such as allowing construction by directley passing parameters into the socket manager.

[MalekiRe]

QUIC as WebTransport should be looked at as the networking standard bevy at least supports, if not prefers.
WebTransport is supported in the browser and solves many issues with TCP while allowing for the ability to send unreliable packets as well emulating the need for UDP support.

[TirushOne]

after having taken a quick look, I can see a compelling argument for QUIC support, but that's a little outside the scope of what I am proposing. But as I said, the idea is to make it super easy to work with TCP and UDP so that other networking abtractions can be build over them. QUIC is a protocal at the user level meaning we can impliment that later if we want to, using what I proposed as a starting point. Reguardless TCP and UDP aren't going anywhere any time soon and are very well supported so I think they should be the first on the list of networking items to add.

[MalekiRe]

In order to work at the browser level ( which is a very large space where bevy exists rn ) we need to either support webrtc or webtransport ( which is based on quic ).

[TirushOne]

dueley noted. But I also figured out how to make the whole system trait based, meaning we could add support for basically any protocol under the sun, but i'll have to look into the exact mechanics of how assembly interacts with the browser and the OS to figure out how to get networking infomation from the browser.

[TirushOne]

for the record after doing some research, unless I am missed something, doing io in the brower using WASM just isn't doible. WASI is the current stand for wasm interfacing with the host enviroment and it isn't designed for browsers. The only other option is to create a custom polyfill in javascript that takes the WASI calls and interprets them, then makes the needed sys calls. It should be self explanitory why that isn't worth it. And from what I have seen, there are no easy solutions for doing io from the browser with wasm of any sort, and it seems this issue is very such still up for debate within WASI development circles. So I don't think networked browser games are going to be a thing with bevy untill there is some concences on if/how WASM should be able to access system resourses from the browser directley, and funtionality for that is intergrated into the rust compiler.