Eggheads: Removing queue delays completely.

[Derek Kuliński]

Hello CoolCold,

Friday, December 30, 2005, 12:16:37 PM, you wrote:

> Take a look at http://eggdrop.org.ru/scripts/putserv_vs_putfast.tcl
> I've wrote this script to eliminate any flood limits eggdrop has in
> it's queues except that are used by modules in C, but i guess this is
> possible too.
> Load this script before all others ( while this is not strictly
> required ). It overrides default putserv/puthelp/putquick commands
> with our own and send data to server without any checks. I hope this
> is what you need.

Woow, I'm in credits (in a very first procedure, what an honor =)))

Anyway, I would like to warn you about putdccraw, it doesn't use any
queue so it's probably what Richard wants, but when I was using it (to
send sharing commands from a tcl script) it didn't behaved well, some
commands didn't go to the bot as they should.
I'm guessing that eggdrop was probably sending his own commands and
putdccraw was cutting between that and sending it's own stuff.

Put that's just my assumption, after I noticed problems I decided not
to use it... Perhaps with server communications there might be no
problems at all...

As for settings maybe this could help a little bit:
You could set net-type to 5, and then:
set use-penalties 0

Some network use penalties, for flood connection, after specific limit
is reached they don't perform any command, but still collecting
commands sent by bot. When the buffer gets full server disconnect the
client. To avoid this, eggdrop also calculates penalties, and waits
when the limit is reached.

After this setting bot will turn that off, but the queues will still
work (so this script still probably will be faster).

I don't belive there is a variable that turns off queues at all, and
most likely to accomplish this you would need to modify server module.

-- 
Best regards,
 Derek                            mailto:takeda at takeda.tk
CCNA, SCSA, SCNA, LPIC, MCP certified
http://www.takeda.tk

The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
-- Edsgar W. Dijkstra