Kevin L. Mitchell writes:
> There are some changes I'd like to make to the server<->server protocol
> for G-lines. The first is, since GNUWorld generates the lastmod
> parameter, I wish to do away with the 3-parameter form of G-line. This
> will hopefully simplify ms_gline() a bit. The second is to solve a
> problem with G-line, and will involve several modifications.
>
> Let's start with a statement of the problem: If an oper issues a very
> long G-line on a domain, then deactivates that G-line, it is impossible
> to set a shorter G-line on the domain. The reason is simple: We have to
> keep the G-line in memory until it would have expired, so that servers
> that may have been split when the G-line was deactivated don't re-issue
> the G-line. The lastmod parameter was added in the last set of G-line
> changes in order to aid in making changes stick, but it does no good if
> the record goes away.
>
> The solution to this is to split the concept of "G-line" into two parts:
> the _ban_ and the _record_. We simply add a second expiration time to
> the G-line protocol message, just before the reason field. (ms_gline()
> uses parv[parc - 1], so this will be backwards-compatible.) This second
> expiration time will be the expiration time of the _record_, rather than
> the _ban_; the ban will expire on time by being automatically
> deactivated, but the record expiration time will be the latest
> expiration time ever issued for that particular G-line: The structure
> describing the G-line won't be destroyed until this record expiration
> time passes.
>
> This change will enable us to, in conjunction with the lastmod
> parameter, change the ban expiration time (or the G-line reason field)
> in whatever way we wish--lengthen it, shorten it, completely deactivate
> it, etc., without fear that the G-line will pop up in some intermediate
> form when some server reconnects to the network. We still won't be able
> to remove a G-line entirely, but we'll now be able to duplicate the
> *effect* of doing so, which should satisfy anyone that has to work
> extensively with G-lines.
I am in favor of this -- I had been writing up some rules for
synchronizing during a burst but had not proven to myself how to
handle the unexpected cases that might be triggered by implementation
bugs. I'll discuss these below.
> In addition to adding a second expiration time, I propose to remove the
> logic that deletes overlapping G-lines, if it's still present in the
> server. It just seems to cause too much trouble, and the G-lines will
> expire of their own accord anyway. We may also want to make changes to
> the way local G-lines work--maybe local G-lines should use a separate
> record, rather than having to be conjoined with the global G-line? But
> then we have to ask the question, how do we make locally-restricted
> changes to the G-line?
I would like to remove overlapped G-lines, too. I'll have to make
implementing trie code a higher priority -- but some of the ideas
apply separately. My thought was that G-line(-like) entries would be
indexed by target, and each target would have both a global and a
local rule. If the local rule is set, it takes precedence over the
global one (only for that target mask). G-lines for * only update the
global rule; G-lines for any other target only update the local rule.
I have been calling the exists-until time on the entry its "lifetime"
rather than its "expiration". When we get a G-line for a target and
local-ness that already exists: the incoming lastmod can be older, the
same or newer than the existing one; and the incoming lifetime can be
longer, the same or shorter than the existing one.
I think that these update rules will avoid desynchs:
A) If incoming lastmod is older, ignore incoming.
B) If incoming lastmod is newer, replace existing.
C) If incoming lastmod is same and lifetime is shorter, ignore
incoming.
D) If incoming lastmod is same and lifetime is longer, replace
existing.
E) If incoming lastmod is same, lifetime is same, and expiration is
later, replace existing.
F) If incoming lastmod is same, lifetime is same, and expiration is
same or sooner, ignore incoming.
I am fuzzy on whether, in the case (B), "replace existing" should keep
the existing lifetime if that is longer. Reflexivity might then
require that case (A) use the incoming lifetime is that is longer.
Also: I use "replace" because a fairly common feature request is to be
able to change the G-line message when activating a G-line that was
previously inactive. If we're going to be changing the G-line code,
we might as well provide that feature once we're happy with the rules
for updating other fields.
Entrope
_______________________________________________
Coder-com mailing list
Coder-com@undernet.org
http://undernet.sbg.org/mailman/listinfo/coder-com
