This is where the web-server will usualy stop parsing, and will leave anything else in the input buffer on hold. This is either where a server module, or wsome other form of CGI interface will read the data.Content-type: text/plain<EOL>
Content-length: 23<EOL>
<EOL>
Code: Select all
set sock [socket -server runsock 4000]
proc runsock {sock address clientport} {
fconfigure $sock -blocking 0
fconfigure $sock -buffering none
fileevent $sock readable [list infohandler $sock]
}
proc infohandler {sock} {
if {[eof $sock]} {
putlog "Connection $sock closed"
close $sock
}
set text [gets $sock]
putlog "OBSERVED: $text"
}
Code: Select all
listen 4000 script observescript
proc observescript { idx } {
control $idx observeprocA
return 0
}
proc observeprocA { idx text } {
putlog "OBSERVE A: ($idx) $text"
if {$text == ""} { return 1 }
putidx $idx "HTTP/1.0 200 OKr"
putidx $idx "Allow: GET, HEAD, POSTr"
putidx $idx "Server: Eggdropr"
putidx $idx "From: eggheadr"
putidx $idx "Content-type: text/plainr"
putidx $idx "Connection: closer"
putidx $idx "r"
control $idx observeprocB
return 0
}
proc observeprocB { idx text } {
putlog "OBSERVE B: ($idx) $text"
if {$text == ""} {
putlog "OBSERVE B: connection closed"
return 1
} else {
putidx $idx "BOUNCING: $textr"
return 0
}
}
What happens if you get rid of the 'return 1' part? Also, maybe you could try HTTP 1.1 instead of 1.0, and/or keep-alive connections.Code: Select all
proc observeprocA { idx text } { putlog "OBSERVE A: ($idx) $text" if {$text == ""} { return 1 } putidx $idx "HTTP/1.0 200 OKr" putidx $idx "Allow: GET, HEAD, POSTr" putidx $idx "Server: Eggdropr" putidx $idx "From: eggheadr" putidx $idx "Content-type: text/plainr" putidx $idx "Connection: closer" putidx $idx "r" control $idx observeprocB return 0 } proc observeprocB { idx text } { putlog "OBSERVE B: ($idx) $text" if {$text == ""} { putlog "OBSERVE B: connection closed" return 1 } else { putidx $idx "BOUNCING: $textr" return 0 } }
That's true. The normal timeout on eggdrop's main loop is 1 second. If there is activity on any connection, like the server, or a dcc chat, then it ends early, so you may see very sporadic response times ranging from near-instant to 1 second.Conclusion from ppslims's post is that the limiting factor for the loop is the internal eggdrop loop, not the TCL loop (if a gets is done on each FILEEVENT trigger i.e. there are as many FILEEVENT triggers as there are lines coming to the socket).
I didn't mean to say it *must* be done like that, I'm just suggesting you do it that way because it is faster and more efficient.Conclusion from stdragon's post is that on an FILEEVENT all available lines must be read from the socket. Although I don't see why all info should be read immediately.
The lowest guaranteed timer resolution is 1 second. Anything less than that and it becomes rather random, since the main loop uses a 1 second timeout interval.There is a buffer anyway (?) Why not read a line every 50 ms controlled by a timer?
You're allowed to do it any way. It's just "supposed" to be done the way I said, that's why there are commands like "fblocked" and "feof" to clarify the situation when "gets" returns -1 in your fileevent handler.Unfortunately, I haven't found any good and thorough reference on the WWW on what is allowed and what not. Any good reference is highly appreciated.
No, eventually it will fill up and stop accepting data until you read some of it, but it won't overflow or lose any data. TCP guarantees that for you (congestion control, resending packets, etc).One question for example: if data is read from the socket in a slow pace -for whatever reason- (say 1 line per 500 ms), does the socket buffer overflow?
To your first question, yes that is a correct conclusion. The second... yes, there are some ugly hacks you could do that wouldn't involve editing the source code. For instance, if you have another bot, connect them via botnet. Then run a script on the 2nd bot that continuously sends garbage over the network. That will force eggdrop's inner loop to spin constantly, eliminating most of the delay.The first option it seems, however, doesn't work when the X milliseconds is set to a low value (say 50 ms). It seems that again the bottleneck is the "loop" time it takes eggdrop to evaluate. Is that a correct conclusion? Is there a way (apart from messing with the internals of eggdrop) to circumvent this?