The Western Isle
valinor | policy | bots | clients | staff | glossary index | search
RFC 2811: Internet Relay Chat: Channel management

 

5.2.5 Server Reop Mechanism


   When a channel has been opless for longer than the "reop delay"
   period and has the channel flag 'r' set (See Section 4.2.7 (Server
   Reop Flag)), IRC servers are responsible for giving the channel
   operator status randomly to some of the members.

   The exact logic used for this mechanism by the current implementation
   is described below.  Servers MAY use a different logic, but that it
   is strongly RECOMMENDED that all servers use the same logic on a
   particular IRC network to maintain coherence as well as fairness.
   For the same reason, the "reop delay" SHOULD be uniform on all
   servers for a given IRC network.  As for the "channel delay", the
   value of the "reop delay" SHOULD be set considering many factors
   among which are the size (user wise) of the IRC network, and the
   usual duration of network splits.

   a) the reop mechanism is triggered after a random time following the
      expiration of the "reop delay".  This should limit the eventuality
      of the mechanism being triggered at the same time (for the same
      channel) on two separate servers.
   b) If the channel is small (five (5) users or less), and the "channel
      delay" for this channel has expired,
        Then reop all channel members if at least one member is local to
        the server.

   c) If the channel is small (five (5) users or less), and the "channel
      delay" for this channel has expired, and the "reop delay" has
      expired for longer than its value,
        Then reop all channel members.

   d) For other cases, reop at most one member on the channel, based on
      some method build into the server. If you don't reop a member, the
      method should be such that another server will probably op
      someone. The method SHOULD be the same over the whole network. A
      good heuristic could be just random reop.
      (The current implementation actually tries to choose a member
      local to the server who has not been idle for too long, eventually
      postponing action, therefore letting other servers have a chance
      to find a "not too idle" member.  This is over complicated due to
      the fact that servers only know the "idle" time of their local
      users)



prev
next

Other Links

  1. IRC Documents
  2. Glossry of IRC terms and abbreviations
  3. How to connect to SorceryNet
  4. List of IRC Client software
  5. Valinor SorceryNet Server Page
  6. SorceryNet Main Site