Originally this was going to simply be a simple chat-server with minimal dependencies,
but I wanted to learn more about how serde and async executors (such as tokio) work internally,
so I made basic implementations of both.
This repo features two main crates; serdy, a small reimplementation of serde and exec, a small async executor.
Notable (non-exhaustive) directories and files:
groupchat/src/bin/: Contains the executable targetsthread_server.rs: A thread-per-connection server implementationasync_server.rs: An async server implementation, usingmiofor I/O. Nearly identical tothread_server.rs, but with async I/Oevent_server.rs: An event-driven server implementationclient.rs: The chat client implementation
groupchat/src/fmt/: Custom binary format implementation for efficient message serializationframed.rs: Message framing implementation
exec/: Contains a basic work-stealing multithreaded executor implementationmio.rs: Amio-based async I/O implementation for use with the executorasync_ch.rsBasic async channel implementations
serdy/: Core serialization framework (similar to serde)serdy-derive/: Procedural macros for deriving serialization implementations
-
Start a server (choose one):
# Thread-per-connection server cargo run --bin thread_server # OR Event-driven server cargo run --bin event_server
-
Connect with one or more clients:
cargo run --bin client
The server will listen for incoming connections, and clients can send messages that will be broadcast to all connected clients.
See module documentation for more information.
To view the full documentation with detailed explanations of the APIs and implementations, run:
cargo doc --openThis will build and open the documentation in your default web browser.
This project was developed as a learning exercises. At some points, there are some easy speed-ups left on the table because they weren't particularly interesting to implement.
For example, instead of a custom lockless channel implementation, a simple mutex-guarded VecDequeue does the same job, just slower.
Similarly, the IO-loop is a busy loop in a separate thread, rather than a tokio-esque reactor that gets ran by the workers when they're free.