"Eating" duplicate lines & putquick is slow

[jola]

Hi!

This simple script executes a binary and just tries to output the result.
BUT the second and third "--------------" lines are never displayed!? Why?

I guess it's either Eggdrop or the ircd that removes 'duplicate lines', or what?
What's the critieria for detecting 'duplicate lines'?
How can I change this behaviour?

I have seen work-arounds by other people, like adding a unique color code to the end f the line with \003xx where xx is a number that gets increased for each line.
But I would like to understand how all this works, before making work-arounds...

This is my first real script, so please help me...

Code: Select all

set outchan "#test"
set binary(REQUESTSHOW) "/glftpd/bin/requestshow"
 
proc killalltimers {} { foreach ut [utimers] { killutimer [lindex $ut 2] } }
killalltimers
 
proc requestshow { } {
  global binary
  global outchan
  utimer 150 requestshow
  putserv "NOTICE $outchan :                              Current requests"
  putserv "NOTICE $outchan :------------------------------------------------------------------------"
  putserv "NOTICE $outchan :UserName -> Request"
  putserv "NOTICE $outchan :------------------------------------------------------------------------"
  foreach line [split [exec $binary(REQUESTSHOW)] \n] {
    putserv "NOTICE $outchan :$line"
  }
  putserv "NOTICE $outchan :------------------------------------------------------------------------"
}
utimer 150 requestshow

BTW:
Eggdrop = 1.6.13
ircd = latest undernet ircd
Everything running on Debian Linux.

[ppslim]

Please try searching the forum before posting.

There are entries in the config file, allowing for duplicate entries in the queue.

Eggdrop, by default, kills duplicates, to prevent flooding and unneeded traffic.

[jola]

SOLUTION to the first problem:
Thanks for the reply, but I searched before, and I did it now again...
But now I searched for 'repeat' instead of trying to search for 'duplicate', so I finally found:
# Allow identical messages in the mode queue?
set double-mode 0
# Allow identical messages in the server queue?
set double-server 0
# Allow identical messages in the help queue?
set double-help 0

FOLLOWUP-1:
It seems like putquick is affected by the double-mode setting, or?

FOLLOWUP-2:
why is putquick so slow? 1-2 seconds per line.
I thought it was supposed to bypass the queue.
Can I speed it up somehow?
And can I speed up the putserv and puthelp too?

[ppslim]

The queues are there to protect your bot from ebing flooded off.

From the looks of the information you wish to post, it would be flooded off rather quick and easily, and I would sugest flood protection (on the script) if you wish to continue.

All the queues are subject to this delay system, yet some more than others. puthelp is there for text dumps like yours, and only sends 1 per second at all, and that is only if the other queues are empty.

I can't remember which, but some some will fast de-queue messages (so long as the setting is eneabled (see config file)) up to a point, then start releasing upto 1 per second.

You can use the undocumented putdccraw command to output information. This bypasses all queues and storage, and is snt direct to the socket.

Code: Select all

putdccraw <idx> <string> <length>

You can send embeded NULLS with putdccraw, so you need to give it a length of the text to send.

IDX is the same as the partyline IDX, yet you can use 0 for the currently connected IRC server.

Code: Select all

set text "PRIVMSG nick :This is a test"
putdccraw 0 $text [string length $text]

[Squirre1]

Actually below is the correct code

Code: Select all

set text "PRIVMSG nick :This is a test" 
putdccraw 0 [string length $text] $text

The string size has to be defined before the text... But anyway.. This still does not work.. It only pipes out about 6 lines and then goes to being controlled by the queue again. almost like a putquick.

There needs to be an optional switch in the config where we can select to use the queue or not be forced to use the queue.

set use_output_queue 1/0

Something like that.

Another thing is that only one person can call the bind at a time, meaning the output is queued in the order it was received.

If person 1 does a !senddata, then person 2, and finally person 3. All the data has to be sent to person 1 before person 2 will get anything, and then finish before person 3 gets anything. If you could make a output queue per nick that the data is being transfered to, the queue system would not be so bad.

I think it needs some major improvements.

[user]

Actually below is the correct code

Code: Select all

set text "PRIVMSG nick :This is a test" 
putdccraw 0 [string length $text] $text

Add a \n to the end of that text