Page 1 of 1

Message throttling

Posted: Sun Aug 06, 2006 10:53 pm
by MalcolmCarmen
Hello, I've been looking through the FAQ and docs, and can't find a relatable subject on this issue.

First of all, I've got the following configured in my fairly generic unrealircd.conf:
sendq 999999999;
recvq 32000;

I'd like normal clients to have no restriction whatsoever on spamming,
since they are mostly trusted bots. The problem is, unreal throttles back PRIVMSGs in both channels and directly to users. I guess this may be a throttle on all data, since the following instances of this problem exist:

1) Client connects, sends multiple (lengthy) PMs to itself or somewhere else. These PMs don't actually reach the target for a few seconds, and even then, are staggered in arrival. They are far from instantaneous.
2) Client sits idle, then sends a lot of messages at once to a single target. The first few messages come through instantly, but the rest are throttled at a constant rate.

I've noticed that using a regular OPER login solves this problem (the oper appears to be able to send as much data as they like, with no in/outbound throttling), but I'd like to avoid doing that with every client!

Thanks a lot for any help you can provide!

Posted: Sun Aug 06, 2006 11:00 pm
by Jobe
In all honesty from what youve described this does sound a tad suspicious to me. In that you're running the server with only trusted bots connecting.

Personally apart from using it as a bot net i cant see meny other uses for a server purely for bots.

Sorry if this offends you in any way but it does look suspicious.

Posted: Sun Aug 06, 2006 11:08 pm
by Stealth
I do need to agree that it does look suspicious... Before providing the solution, I would like to know what the purpose of these bots is.

Posted: Mon Aug 07, 2006 2:53 am
by MalcolmCarmen
That pretty much describes the exact usage, although I'll own the systems this is happening on, heh.

I need a way for bot clients to communicate amongst each other, like an eggdrop link. I am coding these bots in java, so I've basically got to implement the link myself.

I was about to code a server system that allowed bots to become members of the "data link" and share information directly with each other, and with other bots sharing the same tasks, but then realized I was describing an IRC server. These bots will run on 2-3 servers in different locations, but must be able to communicate effeciently (ie: I don't want a single master server relaying messages). As such, I'll link IRCds together, each on one system, to logically save bandwidth and allow inter-box communication...

This project is a version 2 of the following:
http://local-boat.net/index2.php

Since it is dead due to bad original designs, this would be..a blog:
http://local-boat.net/

...And this proves I didn't google it:
http://local-boat.net/malcolmcarmen.txt

If I want to run some illicit botnets, I'll stick to the "uberfastsuperduber 80k unrealircd" distribution ;)

edit: after talking with a friend, it appears it may be a better idea to just go with a lighter IRCd - after all, this isn't an actual network!

Posted: Mon Aug 07, 2006 3:14 am
by Stealth
Ok, seems legit... If anyone else (supporters/coders) have any objections, feel free to rm this post.

In src/include/config.h, look for:

Code: Select all

/** FAKELAG_CONFIGURABLE makes it possible to make certain classes exempted
 * from 'fake lag' (that is, the artificial delay that is added by the ircd
 * to prevent flooding, which causes the messages/commands of the user to
 * slow down). Naturally, incorrect use of this feature can cause SEVERE
 * issues, in fact it can easily bring your whole IRCd down if one of the
 * users with class::options::nofakelag does a good flood at full speed.
 * Hence, this is disabled by default, and you need to explicitly enable it
 * here IF YOU KNOW WHAT YOU ARE DOING. People complaining their ircd
 * ""crashed"" because of this setting will be shot. </DISCLAIMER>
 * Common usage for this are: a trusted bot ran by an IRCOp, that you only
 * want to give "flood access" and nothing else, and other such things.
 */
#undef FAKELAG_CONFIGURABLE
Change the #undef to #define

BE SURE TO READ IT! (Because Syzop says no support for people with it enabled)

Recompile

Do this for all the IRCds

Specify class::options::nofakelag

Posted: Mon Aug 07, 2006 5:02 am
by aquanight
Ideally, that should've been privmsg'd as we don't want the nonlegit people using it? But well, too late now...

Posted: Mon Aug 07, 2006 11:42 pm
by Stealth
aquanight wrote:Ideally, that should've been privmsg'd as we don't want the nonlegit people using it? But well, too late now...
Doesn't really matter, nonlegit people sometimes read the config.h and changelog