The problem
Chat software combines several failure-prone concerns: connections disappear, messages need a shape, and asynchronous code can become difficult to reason about when all responsibilities share one loop.
The approach
FOSSil Chat uses TCP as a clear foundation and Serde for structured data. We kept the protocol deliberately small so that client and server behaviour could be inspected before adding convenience features.
Connection handling, message representation, and application behaviour are treated as separate concerns. This made it possible to reason about what happens when a client disconnects, without mixing that failure path into every message-handling branch. It also gave us a natural place to improve the protocol later.
How I actually built this
- Start small: I began with a functioning CLI message system before introducing a GUI, keeping the protocol visible while the architecture was still moving.
- Setback: connection handling and message processing became too tangled, so disconnect paths were hard to reason about.
- Recovery: I separated the client, server, and shared packet model, then documented the boundaries before adding more features.
The trade-offs
A small custom protocol is less convenient than adopting a fully featured messaging system, but it exposes the mechanics that the project was meant to teach. We accepted that extra implementation work in exchange for learning how framing, serialization, and asynchronous tasks fit together.
What I learned
Async code becomes easier to trust when its boundaries are visible. Separating connection handling, message representation, and application behaviour gave the project room to grow without hiding the important decisions. Working with another developer also reinforced the value of documenting assumptions before they become protocol bugs.