This centralizes formatting related to message logging in a single
place.
git-svn-id: file:///srv/svn/repo/suika/trunk@215 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Any SendMessage call after Close could potentially block forever if the
outgoing channel was filled up. Now the channel is drained before the
writer goroutine exits.
git-svn-id: file:///srv/svn/repo/suika/trunk@209 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This would forward tags even if downstream doesn't support those.
git-svn-id: file:///srv/svn/repo/suika/trunk@192 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This function is only safe to call from inside the user goroutine. Let's
make it private.
git-svn-id: file:///srv/svn/repo/suika/trunk@187 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This allows us to perform cleanup actions in the user goroutine. This
removes the need for pendingLISTsLock.
git-svn-id: file:///srv/svn/repo/suika/trunk@179 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Add bouncer logs, in a network/channel/date.log format, in a similar
manner to ZNC log module. PRIVMSG, JOIN, PART, QUIT, MODE are logged.
Add a config directive for the logs file, including a way to disable
them entirely.
git-svn-id: file:///srv/svn/repo/suika/trunk@178 f0ae65fe-ee39-954e-97ec-027ff2717ef4
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
git-svn-id: file:///srv/svn/repo/suika/trunk@177 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This commit is preparatory work for code that will call
SendMessageLabeled with a direct downstream id rather than a
downstreamConnection pointer.
git-svn-id: file:///srv/svn/repo/suika/trunk@176 f0ae65fe-ee39-954e-97ec-027ff2717ef4
upstreamConn.closed was a bool accessed from different goroutines. Use
the same pattern as downstreamConn instead.
git-svn-id: file:///srv/svn/repo/suika/trunk@175 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Some servers add a trailing space to the channel list in
RPL_WHOISCHANNELS. This commit works around this issue by removing any
empty trailing element after splitting.
Since RPL_WHOISCHANNELS could send an empty channel parameter, we can't
just use strings.TrimRight(s, " "), because splitting on an empty string
would still return an empty element.
Closes: https://todo.sr.ht/~emersion/soju/25
git-svn-id: file:///srv/svn/repo/suika/trunk@174 f0ae65fe-ee39-954e-97ec-027ff2717ef4
NOTICE messages can be both special messages from the server (with no
prefix nick), or regular PRIVMSG-like messages from users. This commit
adds support for marshaling channel and user prefixes in the latter
case.
git-svn-id: file:///srv/svn/repo/suika/trunk@171 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This allows to easily add new events, and also guarantees ordering
between different event types.
git-svn-id: file:///srv/svn/repo/suika/trunk@165 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Following the Go project source code guidelines, id is an abbreviation
and must typically be written as id or ID, not Id.
git-svn-id: file:///srv/svn/repo/suika/trunk@161 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Downstream and upstream message handling are slightly different because
downstreams can send KICK messages with multiple channels or users,
while upstreams can only send KICK messages with one channel and one
user (according to the RFC).
git-svn-id: file:///srv/svn/repo/suika/trunk@159 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Some servers (namely UnrealIRCd) wrongly add a trailing space to the
members parameters of the RPL_NAMREPLY command, which was not handled
correctly.
Adding a trailing space is not legal wrt the IRC specs, but since
UnrealIRCd does it and is in wide use today, we have to work around it.
git-svn-id: file:///srv/svn/repo/suika/trunk@157 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Using labeled-response, the replies to several commands such as NAMES,
WHO, WHOIS can be routed back to a specific downstream, rather than
being broadcast to all downstreams.
For example, after this commit, if the server supports labeled-response,
if a downstream requests the NAMES or WHO or WHOIS of a channel, the
replies of the upstream will only be sent back to that downstream, and
the other downstreams won't receive these messages.
git-svn-id: file:///srv/svn/repo/suika/trunk@156 f0ae65fe-ee39-954e-97ec-027ff2717ef4
NAMES reply for channels currently joined will be returned from cache;
requests for channels not joined will be forwarded from upstream.
git-svn-id: file:///srv/svn/repo/suika/trunk@140 f0ae65fe-ee39-954e-97ec-027ff2717ef4
- Add RPL_ISUPPORT support with CHANMODES, CHANTYPES, PREFIX parsing
- Add support for channel mode state with mode arguments
- Add upstream support for RPL_UMODEIS, RPL_CHANNELMODEIS
- Request channel MODE on upstream channel JOIN
- Use sane default channel mode and channel mode types
git-svn-id: file:///srv/svn/repo/suika/trunk@139 f0ae65fe-ee39-954e-97ec-027ff2717ef4
- Fix replies without client as first argument
- Replace wrong prefix check with a proper entity type check
git-svn-id: file:///srv/svn/repo/suika/trunk@129 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This allows message handlers to read upstream/downstream connection
information without causing any race condition.
References: https://todo.sr.ht/~emersion/soju/1
git-svn-id: file:///srv/svn/repo/suika/trunk@103 f0ae65fe-ee39-954e-97ec-027ff2717ef4
