#94 Network Parameters

open
nobody
None
5
2010-03-01
2010-03-01
No

Certain ircu configuration options need to be synchronized across a network, such as SERVER_PORT, PROVIDER, HIDDEN_HOST, etc. Other settings should ideally be synchronized, such as NICKLEN or IPCHECK_CLONE_LIMIT. Still others should never be synchronized, such as RELIABLE_CLOCK or HUB. At present, such synchronization requires that all ircd.conf files be updated for any changes. This can work well in instances where temporary desynchronization can be tolerated; however, as we contemplate such things as changing ircu's case mapping, such desynchronization becomes more problematic. I would like to therefore propose an enhancement to ircu to add "network parameters."

Network parameters are configuration settings--not necessarily feature settings, although the features subsystem provides a convenient hook for them--which are distributed over the network. To hook them into the features subsystem, we'd mark some features as unsynchronizable with a NOSYNC flag, to make sure that such features as RELIABLE_CLOCK never get accidentally synchronized; all other features would be potentially synchronizable via the network parameters system. Network parameters exist as a two-level system; there are network-overridable parameters (expressed as a "key*=value" sequence), and network-locked parameters (expressed as a "key=value" sequence). The overridable parameters essentially express a default setting for the feature, which can be overridden in the server's configuration file; locked parameters, on the other hand, would override any setting for that feature that might be listed in the configuration file.

To accomplish this, we need protocol extensions that can send the current slate of network parameters (even if expressing them requires more than one PDU) during burst (probably right after the SERVER message in the handshake), as well as protocol that enables them to be updated--features added or removed from the tracked parameters, or values changed. In addition, some sort of version stamp will also need to be attached to network parameters for synchronization purposes.

For each parameter, we have 3 possible operations: add the parameter to the list of tracked parameters; update the value or type (overridable vs. locked) of the parameter; and remove the parameter from the list of tracked parameters. In addition, we need a way to forward the entire set of parameters at once, for netburst synchronization. I propose a new command, PARAM (token PA) with two different forms:

1) <origin> PA * <timestamp> ([+]<param>[*]=<value>|-<param>)[,(...)]

This form is used for performing one of the three operations on parameter settings. In the '+' form (where the '+' may be optional), the parameter is added to the tracked set and/or its value and type are updated. In the '-' form, the parameter is removed from the tracked set. Multiple parameter updates may be provided in the same message by separating them with ','. The <timestamp > would be greater than the current timestamp attached to the parameter settings.

2) <origin> PA <seq> <timestamp> <param>[*]=<value>[,(...)]

This form is used for updating the entire set of tracked network parameters, and is the form used on burst. The <timestamp> is compared with the current timestamp attached to the parameter settings, and, if it is greater, will be propagated on to the rest of the network. The <seq> field is intended to differentiate the second form from the first form, and for grouping together multiple PA messages in the case where the tracked set exceeds the 510 maximum character limit of IRC messages. This <seq> must reliably indicate the end of the sequence; the parameter set would not be installed or propagated unless and until the last PA message was received. This requirement prevents an incomplete burst from desynchronizing the network parameters in such a way that they would have to be re-issued with a higher timestamp. I propose that <seq> be "-" for all of the messages except the last, where it would be "/", but I'm open to other suggestions.

I am deliberately not specifying how these network parameter settings would be initially introduced into the network. I presume that this would be done through some sort of operator service, such as Uworld, which would be able to apply appropriate access controls on a global basis. Also, although I have talked about the features subsystem, it is not necessarily a requirement that network parameters be tied to features; it may be desirable to have other configuration settings be synchronized. Additionally, the network parameter system may choose to squit servers that have incompatible settings, such as a case where one server has been compiled with MAXNICKLEN less than the network parameter setting of NICKLEN (with an appropriate message describing the problem).

Thoughts? Discussion about protocol issues? Implementation issues?

Discussion

  • ThiefMaster
    ThiefMaster
    2010-03-01

    I don't think IPCHECK_CLONE_LIMIT should be synchronized.
    On GameSurge we have IPCHECK_CLONE_LIMIT set to a very high value on some privileged servers so people do not have "reconnecting too fast" issues there. Additionally it might be something where some networks want to leave the maximum up to server admins - similar to MAXCHANNELS.

    However, "syncing" MAXNICKLEN/NICKLEN would be very important. Since the MAXNICKLEN is controlled via a #define though, a server needs to be rejected during burst when it's below the network's MAXNICKLEN (currently linking a server with a low (MAX)NICKLEN is extremely bad as it kills all users with longer nicks)

     
  • ThiefMaster
    ThiefMaster
    2010-03-01

    Oh, didn't read your last paragraph.. so forget my NICKLEN comment ;)

     
  • At this level, I'm not at all interested in the specific features that should or should not be synchronized; I'm only interested in discussing whether the mechanism is worth implementing and if the suggested implementation makes sense. We can discuss the specific configuration settings that should or should not be synchronized later.

     
  • Jason
    Jason
    2010-03-10

    I think it's worth implementing, if for no other reason that updating multiple configuration files is tedious and error prone. This would at least somewhat insure certain settings get propagated across the entire network, almost instantly.

    The suggested implementation makes sense, and as you hinted to, such settings should initially be introduced by an operator service, such as uWorld.