This is the next iteration of allonet, the fundamental networking library that underpins the distributed and collaborative 3D/VR/AR workspace Alloverse. It is not yet ready to replace version 1, but its general shape is taking form and active development is now happening here.
Allonet allows the writing of three different kinds of software:
- Alloapps: "widget" apps that run in a 3D space. They run server-side but have an API that feels client-side. They're built towards a "UI library" built on top of allonet.
- Visor: The 3D application(s) used to visualize these apps and other uses. Basically a 3D web browser.
- Place: The "simulation server"/network hub that users and apps connect to.
Allonet 1 was written in C, because I have decades of experience in C, and I know how to make it work on pretty much any platform. However, the constant memory corruption, lack of abstraction, and lack of a standard library worth mentioning is a pain.
Requirements for a rewrite:
- Interfaces with C, so that it can be used with C FFI from C#, lua, C++, Java, etc, and integrated with any game engine or app platform
- Language must be modern and object oriented, and also suitable for functional programming, good support for async and threading
- Must have a package manager and a wide library of functionality.
Both Swift and Rust match these. Rust won't play well with my brain, despite many tries. So Swift it is.
Allonet was always supposed to use a web-compatible udp-like protocol, probably WebRTC. Now years later, I'm more keen on QUIC or WebTransport, but there are no working libraries for them for Swift, so I'll lean on WebRTC once again.
Thoughts on WebRTC signalling. We'll ignore p2p for now and use a server-client model. This means that the server's sdp will never change, and renegotiation is not as important. So, we don't need an active signalling channel, but instead use a single HTTPS call to exchange handshakes.
The worst part about Allonet 1 was JSON. It was horribly inefficient. We'll aim for ProtoBuf this time, but lean on BinaryCodable as a stop-gap to just prototype before we start messing with schemas.
One fun thing we could do is dynamic schemas: each agent shares the schemas it will publish data using (i e, which components it supports); placeserv merges to one large schema, and publishes that back to agents as the authoritative.
git submodule update --init --recursive # AlloDataChannel etc; required
swift build # first build downloads a large webrtc xcframework
swift run AlloPlace -n "Local Place"AlloPlace is the place server. Useful flags: -p HTTP signalling port (default
9080), -t token that AlloApps must present (omit to allow any app), -u UDP port
range for WebRTC, --app-name/--app-url-protocol to brand the landing page for a
custom client. Clients connect with an alloplace2://host:port URL; signalling is a single POST, over
HTTP for localhost and HTTPS when a TLS proxy fronts the place. Everything after that runs
over WebRTC data channels (CBOR-encoded).
Also runnable from Xcode: open the package, pick the AlloPlace scheme, set the same flags as Run arguments.
- Install Swift 5.9
- Launch a Developer PowerShell For Visual Studio 2019 in Windows Terminal
swift build