OS/2 Shareware BBS: 35 Internet/35-Internet.zip/ircd_os2.zip/README.TSora

Text File | 1996-01-06 | 15KB | 321 lines

                       Protocol changes for +TSora
                       ---------------------------


Note:

The protocols described here implement TimeStamps on IRC channels and
nicks. The idea of IRC TimeStamps was started on Undernet, and first
implemented by Run <[e-mail]>. The protocols used here
are not exactly the same as the ones used on Undernet; the nick-kill
handling is very similar and must be credited to Run, while the
"TimeStamped channel description" protocol is quite different.



TSora servers keep track of which version of the TS protocol (if any)
their neighboring servers are using, and take it into account when
sending messages to them. This allows for seamless integration of TS
servers into a non-TS net, and for upgrades of the protocol.

Each server knows which is the lowest and the highest version of the
TS protocol it can interact with; currently both of these are set to 1:

#define TS_CURRENT 1        /* the highest TS ver we can do */
#define TS_MIN 1        /* the lowest TS ver we can do  */


Timings and TS versions:
========================

. Keep a 'delta' value to be added to the result of all calls to time(),
  initially 0.

. Send a

  SVINFO <TS_CURRENT> <TS_MIN> <STANDALONE> :<UTC-TIME>

  before "SERVER" and after "PASS", where <STANDALONE> is 1 if we're
  connected to more TSora servers, and 0 if not, and <UTC-TIME> is our
  idea of the current UTC time, fixed with the delta.

. When we receive a "SVINFO <x> <y> <z> :<t>" line from a connecting
  server, we ignore it if TS_CURRENT<y or x<TS_MIN, otherwise we
  set a flag remembering that that server is TS-aware, remember the TS
  version to use with it (min(TS_CURRENT, x)). Additionally, if this is
  our first connected TS server, we set our delta to t-<OUR_UTC> if
  z==0, and to (t-<OUR_UTC>)/2 if z!=0. The SVINFO data is kept around
  until the server has effectively registered with SERVER, and used
  *after* sending our own SVINFO to that server.


Explanations:

  Servers will always know which of their directly-linked servers
  can do TS, and will use the TS protocol only with servers that
  do understand it. This makes it possible to switch to full TS
  in just one code-replacement step, without incompatibilities.

  As long as not all servers are TS-aware, the net will be divided
  into "zones" of linked TS-aware servers. Channel modes will be
  kept synchronized at least within the zone in which the channel
  was created, and nick collisions between servers in the same
  zone will result in only one client being killed.

  Time synchronization ensures that servers have the same idea of the
  current time, and achieves this purpose as long as TS servers are
  introduced one by one within the same 'zone'. The merging of two zones
  cannot synchronize them completely, but it is to be expected that
  within each zone the effective time will be very close to the real
  time.

  The current time is only used when setting a TS on a new channel or
  nick, and once such a TS is set, it is never modified because of
  synchronization, as it is much more important that the TS for a
  channel or nick stays the same across all servers than that it is
  accurate to the second.

  Note that Undernet's 2.8.x servers have no time synchronization at
  all, and have had no problems because of it - all of this is more to
  catch the occasional server with a way-off clock than anything.


NICK handling patches (anti-nick-collide + shorter connect burst):
==================================================================

. For each nick, store a TS value = the TS value received if any, or our
  UTC+delta at the time we first heard of the nick. TS's are propagated
  to TS-aware servers whenever sending a NICK command.

. Nick changes reset the TS to the current time.

. When sending a connect burst to another TS server, replace the
  NICK/USER pair with only one NICK command containing the nick, the
  hopcount, the TS, the umode, and all the USER information.

  The format for a full NICK line is:
  NICK <nick> <hops> <TS> <umode> <user> <host> <server> :<ircname>

  The umode is a + followed by any applying usermodes.

  The format for a nick-change NICK line is:
  :<oldnick> NICK <newnick> :<TS>

. When a NICK is received from a TS server, that conflicts with an
  existing nick:
  + if the userhosts differ or one is not known:
    * if the timestamps are equal, kill ours and the old one if it
      was a nick change
    * if the incoming timestamp is older than ours, kill ours and
      propagate the new one
    * if the incoming timestamp is younger, ignore the line, but kill
      the old nick if it was a nick change
  + if the userhosts are the same:
    * if the timestamps are equal, kill ours and the old one if it
      was a nick change
    * if the incoming timestamp is younger, kill ours and propagate
      the new one
    * if the incoming timestamp is older, ignore the line but kill
      the old nick if it was a nick change

. When a NICK is received from a non-TS server that conflicts with
  an existing nick, kill both.

. Do not send "Fake Prefix" kills in response to lines coming from TS
  servers; the sanitization works anyway, and this allows the "newer
  nick overruled" case to work.

Explanations:

  The modified nick-introduction syntax allows for a slightly shorter
  connect-burst, and most importantly lets the server compare
  user@host's when determining which nick to kill:  if the user@host
  is the same, then the older nick must be killed rather than the
  newer.

  When talking to a non-TS server, we need to behave exactly like one
  because it expects us to. When talkign to a TS server, we don't kill
  the nicks it's introducing, as we know it'll be smart enough to do it
  itself when seeing our own introduced nick.

  When we see a nick arriving from a non-TS server, it won't have a TS,
  but it's safe enough to give it the current time rather than keeping
  it 0; such TS's won't be the same all across the network (as long as
  there is more than one TS zone), and when there's a collision, the TS
  used will be the one in the zone the collision occurs in.

  Also, it is important to note that by the time a server sees (and
  chooses to ignore) a nick introduction, the introducing server has
  also had the time to put umode changes for that nick on its queue, so
  we must ignore them too... so we need to ignore fake-prefix lines
  rather than sending kills for them. This is safe enough, as the rest
  of the protocol ensures that they'll get killed anyway (and the
  Undernet does it too, so it's been more than enough tested). Just for
  an extra bit of compatibility, we still kill fake prefixes coming from
  non-TS servers.

  This part of the TS protocol is almost exactly the same as the
  Undernet's .anc (anti-nick-collide) patches, except that Undernet
  servers don't add usermodes to the NICK line.


TimeStamped channel descriptions (avoiding hacked ops and desynchs):
====================================================================

. For each channel, keep a timestamp, set to the current time when the
  channel is created by a client on the local server, or to the received
  value if the channel has been propagated from a TS server, or to 0
  otherwise. This value will have the semantics of "the time of creation
  of the current ops on the channel", and 0 will mean that the channel
  is in non-TS mode.

  A new server protocol command is introduced, SJOIN, which introduces
  a full channel description: a timestamp, all the modes (except bans),
  and the list of channel members with their ops and voices. This
  command will be used instead of JOIN and of (most) MODEs both in
  connect bursts and when propagating channel creations among TS
  servers. SJOIN will never be accepted from or sent to users.

  The syntax for the command is:

  SJOIN <TS> #<channel> <modes> :[@][+]<nick_1> ...  [@][+]<nick_n>

  The fields have the following meanings:

  * <TS> is the timestamp for the channel

  * <modes> is the list of global channel modes, starting with a +
    and a letter for each of the active modes (spmntkil), followed
    by an argument for +l if there is a limit, and an argument for
    +k if there's a key (in the same order they were mentioned in
    the string of letters).

    A channel with no modes will have a "+" in that field.

    A special value of "0" means that the server does not specify the
    modes, and will be used when more than one SJOIN line is needed
    to completely describe a channel, or when propagating a SJOIN
    the modes of which were rejected.

  * Each nick is preceded by a "@" if the user has ops, and a "+" if
    the user has a voice. For mode +ov, both flags are used.

  SJOINs will be propagated (when appropriate) to neighboring TS
  servers, and converted to JOINs and MODEs for neighboring non-TS
  servers.

  To propagate channels for which not all users fit in one
  SJOIN line, several SJOINs will be sent consecutively, only the first
  one including actual information in the <mode> field.

  An extra ad-hoc restriction is imposed on SJOIN messages, to simplify
  processing: if a channel has ops, then the first <nick> of the first
  SJOIN sent to propagate that channel must be one of the ops.

  Servers will never attempt to reconstruct a SJOIN from JOIN/MODE
  information being received at the moment from other servers.

. For each user on a channel, keep an extra flag (like ops and voice)
  that is set when the user has received channel ops from another
  server (in a SJOIN channel description), which we rejected (ignored).
  Mode changes (but NOT kicks) coming from a TS server and from someone
  with this flag set will be ignored. The flag will be reset when the
  user gets ops from another user or server.

. On deops done by non-local users, coming from TS servers, on channels
  with a non-zero TS, do not check that the user has ops but check that
  their 'deopped' flag is not set. For kicks coming from a TS server, do
  not check either. This will avoid desynchs, and 'bad' modechanges are
  avoided anyway. Other mode changes will still only be taken into
  account and propagated when done by users that are seen as having ops.

. When a MODE change that ops someone is received from a server for a
  channel, that channel's TS is set to 0, and the mode change is
  propagated.

. When a SJOIN is received for a channel, deal with it in this way:
  * received-TS = 0:
    + if we have ops or the SJOIN doesn't op anyone, SJOIN propagated
      with our own TS.
    + otherwise, TS set to 0 and SJOIN propagated with 0.
  * received-TS > 0, own-TS = 0:
    + if the SJOIN ops someone or we don't have ops, set our TS to the
      received TS and propagate.
    + otherwise, propagate with TS = 0.
  * received-TS = own-TS: propagate.
  * received-TS < own-TS:
    + if the SJOIN ops someone, remove *all* modes (except bans) from
      the channel and propagate these mode changes to all neighboring
      non-TS servers, and copy the received TS and propagate the SJOIN.
    + if the SJOIN does not op anyone and we have ops, propagate
      with our own TS.
    + otherwise, copy the received TS and propagate the SJOIN.
  * received-TS > own-TS:
    + if the SJOIN does not introduce any ops, process and propagate
      with our own TS.
    + if we have ops: for each person the mode change would op, set the
      'deopped' flag; process all the JOINs ignoring the '@' and '+'
      flags; propagate without the flags and with our TS.
    + if we don't have ops: set our TS to the received one, propagate
      with the flags.


Explanations:

  This part of the protocol is the one that is most different (and
  incompatible) with the Undernet's: we never timestamp MODE changes,
  but instead we introduce the concept of time-stamped channel
  descriptions. This way each server can determine, based on its state
  and the received description, what the correct modes for a channel
  are, and deop its own users if necessary. With this protocol, there is
  *never* the need to reverse and bounce back a mode change. This is
  both faster and more bandwith-effective.

  The end goal is to have a protocol will eventually protect channels
  against hacked ops, while minimizing the impact on a mixed-server net.
  In order to do this, whenever there is a conflict between a TS server
  and a non-TS one, the non-TS one's idea of the whole situation
  prevails. This means that channels will only have a TS when they have
  been created on a TS-aware server, and will lose it whenever a server
  op comes from a non-TS server. Also, at most one 'zone' will have a TS
  for any given channel at any given time, ensuring that there won't be
  any deops when zones are merged. However, when TS zones are merged, if
  the side that has a TS also has ops, then the TS is kept across the
  whole new zone. Effective protection will only be ensured once all
  servers run TS patches and channels have been re-created, as there is
  no way servers can assign a TS to a channel they are not creating
  (like they do with nicks) without having unwanted deops later.

  The visible effects of this timestamped channel-description protocol
  are that when a split rejoins, and one side has hacked ops, the other
  side doesn't see any server mode changes (just like with Undernet's
  TS), but the side that has hacked ops sees:

  * first the first server on the other side deopping and devoicing
    everyone, and fixing the +spmntkli modes
  * then other users joining, and getting server ops and voices

  The less obvious part of this protocol is its behavior in the case
  that the younger side of a rejoin has servers that are lagged with
  each other. In such a situation, a SJOIN that clears all modes and
  sets the legitimate ones is being propagated from one server, and
  lagged illegitimate mode changes and kicks are being propagated in the
  opposite direction. In this case, a kick done by someone who is being
  deopped by the SJOIN must be taken into account to keep the name list
  in sync (and since it can only be kicking someone who also was on the
  younger side), while a deop does not matter (and will be ignored by
  the first server on the other side), and an opping *needs* to be
  discareded to avoid hacked ops.

  The main property of timestamped channel descriptions that makes them
  a very stable protocol even with lag and splits, is that they leave a
  server in the same final state, independently of the order in which
  channel descriptions coming from different servers are received. Even
  when SJOINs and MODEs for the same channel are being propagated in
  different direction because of several splits rejoining, the final
  state will be the same, independently of the exact order in which each
  server received the SJOINs, and will be the same across all the
  servers in the same zone.