soju forked to be LESS SHIT
10ea698022
This commit adds support for downstream LIST messages from multiple concurrent downstreams to multiple concurrent upstreams, including support for multiple pending LIST requests from the same downstream. Because a unique RPL_LISTEND message must be sent to the requesting downstream, and that there might be multiple upstreams, each sending their own RPL_LISTEND, a cache of RPL_LISTEND replies of some sort is required to match RPL_LISTEND together in order to only send one back downstream. This commit adds a list of "pending LIST" structs, which each contain a map of all upstreams that yet need to send a RPL_LISTEND, and the corresponding LIST request associated with that response. This list of pending LISTs is sorted according to the order that the requesting downstreams sent the LIST messages in. Each pending set also stores the id of the requesting downstream, in order to only forward the replies to it and no other downstream. (This is important because LIST replies can typically amount to several thousands messages on large servers.) When a single downstream makes multiple LIST requests, only the first one will be immediately sent to the upstream servers. The next ones will be buffered until the first one is completed. Distinct downstreams can make concurrent LIST requests without any request buffering. Each RPL_LIST message is forwarded to the downstream of the first matching pending LIST struct. When an upstream sends an RPL_LISTEND message, the upstream is removed from the first matching pending LIST struct, but that message is not immediately forwarded downstream. If there are no remaining pending LIST requests in that struct is then empty, that means all upstreams have sent back all their RPL_LISTEND replies (which means they also sent all their RPL_LIST replies); so a unique RPL_LISTEND is sent to downstream and that pending LIST set is removed from the cache. Upstreams are removed from the pending LIST structs in two other cases: - when they are closed (to avoid stalling because of a disconnected upstream that will never reply to the LIST message): they are removed from all pending LIST structs - when they reply with an ERR_UNKNOWNCOMMAND or RPL_TRYAGAIN LIST reply, which is typically used when a user is not allowed to LIST because they just joined the server: they are removed from the first pending LIST struct, as if an RPL_LISTEND message was received |
||
|---|---|---|
| cmd | ||
| config | ||
| doc | ||
| .build.yml | ||
| .gitignore | ||
| bridge.go | ||
| db.go | ||
| downstream.go | ||
| go.mod | ||
| go.sum | ||
| irc.go | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| ring.go | ||
| schema.sql | ||
| server.go | ||
| service.go | ||
| upstream.go | ||
| user.go | ||
soju
A user-friendly IRC bouncer.
- Multi-user
- Support multiple clients for a single user, with proper backlog synchronization
- Support connecting to multiple upstream servers via a single IRC connection to the bouncer
Usage
sqlite3 soju.db <schema.sql
go run ./cmd/sojuctl create-user <username>
go run ./cmd/soju
Then connect with username <username>@chat.freenode.net and join #soju.
See the man page at soju.1.scd for more information.
Contributing
Send patches on the mailing list or on GitHub, report bugs on the issue tracker. Discuss in #soju on Freenode.
License
AGPLv3, see LICENSE.
Copyright (C) 2020 Simon Ser