this little bug has not had the hobby juices but i'm forcing it to happen again today.
before I ran out of steam the big thing I was in the middle of was taking a first crack at a user friendly API wrapper around all the components & concepts i've jammed out so far.
no one wants to get a PhD in some library and all the ways to use it unless they really have to. the goal of a networking library is to help application writers wire up connections and send/receive data on those connections.
The most I want people to really think about is a small set of features my protocol has tried to achieve:
- 31 arbitrarily configurable 'streams'
- out of the box "just should work" chacha20 encryption without having to futz with x509 certs manually etc.
- some basic fragmentation & reassembly on some stream types
- fast enough
I took what I think/hope is a good approach in keeping a lot of these core ideas and components relatively loosely coupled and composed by messier middle-tier code that brings the feature promises together.
Currently a user would have to know how all these little things fit together as written and it's still a far cry from just networking_library.start_connection("remotehost.game:27015")
As I was writing my final outer layer to simplify all these ideas, I've come to realize a few missing pieces still.
One big piece is that my core networking behavior does not prescribe a protocol or behavior for important ideas like encryption key rotations, or stream assembling/deconstructing. I made a principled choice to treat these outcomes as application concerns. Right now the one big thing the library prescribes/forces is a "system stream", which is reliable-ordered and required to be constructed for a game connection.
Right now I'm putting together a "wrapper" crate for both clients/servers that will likely be what my initial game-engine uses will ultimately bridge to via whatever FFI is appropriate. This wrapper ultimately provides a tokio::task that injects itself as a filter to the OOTB system_stream and can automatically do things like key rotations, or detect a dead connection, etc.
If all goes well I should have a really nice "dummy-proof" wrapper around this library and can start really using it in an engine like Unity or maybe I'll even play around with UE5. I don't have any interesting code samples or technical problems to solve to add to this post but it helps me sort my thoughts out. Thanks!