AW: [IRCServices] Faster AKILL Processing...

[Yusuf Iskenderoglu]

Hi again;

I've merged my thoughts about this topic and came to the following option,
which probably decrease the load on services.

You could set up another set of services, which is started in -skeleton, leading to
everything but OperServ disabled, and advisable is not to use confusing nicknames
for the known part of services. That OperServ can be used to place akills, and manage akills,
and remove akills etc, without taking any time from the real services which still continue working.

I think your opers should not be that much unhappy having to identify to let's say ServBot in order to
use the *new* AkillServ. 

Regards,

---------------------------------
Yusuf Iskenderoglu
eMail - uhc0 at rz.uni-karlsruhe.de 
eMail - s_iskend at ira.uka.de
ICQ : 20587464 \ TimeMr14C
---------------------------------

> -----Ursprungliche Nachricht-----
> Von: owner-ircservices at ender.shadowfire.org
> [mailto:owner-ircservices at ender.shadowfire.org]Im Auftrag von Jonathan
> Morton
> Gesendet: Wednesday, July 19, 2000 7:56 PM
> An: ircservices at delirious.shadowfire.org
> Betreff: Re: AW: [IRCServices] Faster AKILL Processing...
> 
> 
> >Therefore it is in my opinion, adviseable to let services manage akills,
> >instead of any server on a network,
> >that even do not need to.
> 
> I thought the argument was to distribute the processing across 
> the servers,
> rather than having the _entire_ load on Services.  If the services machine
> is more powerful than all the others put together, and network latency is
> low, then it makes great sense to match them all on Services, then issue
> /kill and /kline from there.  Also, _if_ troublemakers tend to come back
> infrequently compared to the reboot frequency, then this is an acceptable
> solution.  However, I suspect that neither of these assumptions holds true
> for many networks.
> 
> The solution of keeping every server updated with a K-line list has it's
> own problems, though.  With a large list of AKILLs and a large number of
> servers, the traffic caused by the updates could become significant and
> lead to further problems.  However this is exactly the situation where the
> distribution of processing would be most useful.  Throttling 
> would probably
> be the best solution to the "flooding" problem, using a 'trickle' 
> of /kline
> commands to update the remote server(s), possibly even with a delay to
> allow the usual "recovering from netsplit" traffic to subside.  This
> completely frees up Services from the usual burden of matching AKILLs and
> allows it to concentrate on it's other tasks in a more "managerial" role.
> 
> Again, this would best be configurable as an admin option, as with all
> major behavioural changes.
> 
> --------------------------------------------------------------
> from:     Jonathan "Chromatix" Morton
> mail:     chromi at cyberspace.org  (not for attachments)
> uni-mail: j.d.morton at lancaster.ac.uk
> 
> The key to knowledge is not to rely on people to teach you it.
> 
> Get VNC Server for Macintosh from <A  HREF="http://chromatix.autistics.org/vnc/">http://chromatix.autistics.org/vnc/</A>
> 
> -----BEGIN GEEK CODE BLOCK-----
> Version 3.12
> GCS$/E/S dpu(!) s:- a19 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
> PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
> -----END GEEK CODE BLOCK-----
> 
> 
> 
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo at ender.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.
> 


---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.