For discussion... -- Kevin L. Mitchell <klmi...@mit.edu>
--- Begin Message ---Feature Requests item #2960960, was opened at 2010-02-28 21:17 Message generated for change (Tracker Item Submitted) made by klmitch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=504083&aid=2960960&group_id=63470Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin L. Mitchell (klmitch) Assigned to: Nobody/Anonymous (nobody) Summary: Network Parameters Initial Comment: 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=504083&aid=2960960&group_id=63470
--- End Message ---
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
