source: code/trunk/doc/architecture.md@ 264

Last change on this file since 264 was 227, checked in by contact, 5 years ago

Remove per-network ring buffer goroutines

Just dispatch from the user goroutine. This allows removes a lot of complexity.

File size: 1.4 KB
RevLine 
[170]1# soju architecture
2
3soju manages two types of connections:
4
5- Upstream connections: soju maintains persistent connections to
6 user-configured IRC servers
7- Downstream connections: soju accepts connections from IRC clients
8
9On startup, soju will iterate over the list of networks stored in the database
10and try to open an upstream connection for each network.
11
12## Ring buffer
13
14In order to correctly send history to each downstream client, soju maintains
15for each network a single-producer multiple-consumer ring buffer. The network's
16upstream connection produces messages and multiple downstream connections
17consume these messages. Each downstream client may have a different cursor in
18the history: for instance a client may be 10 messages late while another has
19consumed all pending messages.
20
21## Goroutines
22
23Each type of connection has two dedicated goroutines: the first one reads
24incoming messages, the second one writes outgoing messages.
25
26Each user has a dedicated goroutine responsible for dispatching all messages.
27It communicates via channels with the per-connection reader and writer
28goroutines. This allows to keep the dispatching logic simple (by avoiding any
29race condition or inconsistent state) and to rate-limit each user.
30
31The user dispatcher goroutine receives from the `user.events` channel. Upstream
32and downstream message handlers are called from this goroutine, thus they can
33safely access both upstream and downstream state.
Note: See TracBrowser for help on using the repository browser.