| View previous topic :: View next topic |
| Author |
Message |
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
 Posted: Mon Mar 23, 2009 6:45 pm Post subject: |
 |
|
Proper code...
| Quote: | | fileevent readable NEVER works and fileevent writable ALWAYS works- even if the conneection isn't! |
Work as in triggering?
This requires an understanding of when a channel is considered readable or writable. To quote the fileevent manpage:
| Quote: | A channel is considered to be readable if there is unread data available on the underlying device. A channel is also considered to be readable if there is unread data in an input buffer, except in the special case where the most recent attempt to read from the channel was a gets call that could not find a complete line in the input buffer. This feature allows a file to be read a line at a time in nonblocking mode using events. A channel is also considered to be readable if an end of file or error condition is present on the underlying file or device. It is important for script to check for these conditions and handle them appropriately; for example, if there is no special check for end of file, an infinite loop may occur where script reads no data, returns, and is immediately invoked again.
A channel is considered to be writable if at least one byte of data can be written to the underlying file or device without blocking, or if an error condition is present on the underlying file or device. |
As I stated in my previous post, you leave the writable event going, which means it'll trigger over and over and ... I thought I mentioned that writable also includes error conditions, but I guess I missed it. Nevertheless my code handles it.
As you fail to close the socket, should any error condition arise, the socket will remain writable. Since your proc never raises an error condition, fileevent will never drop the event handler by it's own either. Hence you get an infinite loop. But that, I already mentioned in my previous post...
Oh, and if I was not clear enough, the reason for your 5min freeze in that other post.. this is the very line that causes it:
| Code: | | while {(![eof $PlaySock])} {set PlayInfo [gets $PlaySock];} |
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
 |
dj-zath
Op
Joined: 15 Nov 2008
Posts: 134
|
| Posted: Tue Mar 24, 2009 1:48 am Post subject: |
|
|
UPDATE!
| Code: |
proc RacSkt {} {
global RacIP RacPort RacInfo
if {([catch {set RacInfo [exec fetch -q -A -m -T 1 -o - http://$RacIP:$RacPort/x/playing.cgi];};])} {
putlog {Connection NOT present};
return 0;
} else {
putlog {Connection present!};
return 0;
};
}
|
WORKS LIKE A CHARM!
and its simple, it doesn't hang the bot, doesn't flood the stack with dead sockets, reads the states and data reliably and, most-importantly, its FASSSSST!
timeout is 1 sec.. PLENTY of time to read and close and it reads/closes everytime! no more dead sockets or fin_wait_2s!
admittingly, I'm still testing.. but I am quite excited at the results so far...
it PASSED the "no connect/connect/no connect" test- something TCL on its own was completely UNABLE to do...
fetch is a basic internal command to FreeBSD so its included as a "freebie" and I'm really impressed- I donno why I didn't think of this before! (okay, actually, I did.. but I couldn't get it working...)
I have more testing to do.. but this is looking REALLY GOOD so far!
MORE UPDATES:
more tests were done 100% SUCCESS!
it CAN read ICECAST PERFECTLY!
it will even AUTH in properly as well; NIIIIIICE!!!
oh this changes EVERYTHING...
-DjZ-
 |
|
| Back to top |
|
|
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
| Posted: Tue Mar 24, 2009 2:21 pm Post subject: |
|
|
Glad you got it working.
Keep in mind, it was not tcl that did not pass your "no connect/connect/no connect" test, but rather your tcl-coding.
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
|
dj-zath
Op
Joined: 15 Nov 2008
Posts: 134
|
| Posted: Wed Mar 25, 2009 3:08 am Post subject: |
|
|
| NML-375 wrote: | | Keep in mind, it was not tcl that did not pass your "no connect/connect/no connect" test, but rather your tcl-coding. |
yes, I spoke out of exciitement
I shall rephrase...
This code passed the "no connect/connect/no connect" test in which I was unable to get TCL to do properly on its own.
I didn't mean to imply that TCL was at fault.. its true that my coding skills in TCL aren't that advanced (though, I gotta admit, I think I did pretty darn good for what I have to work with).
I also mis-stated about "fetch" being included with FreeBSD.. to state properly: *I* found that, after installing a bare-bones version of FreeBSD 6x and then installing SOME "ports" and then uninstalling them, I note that, the command "fetch" was available; "wget", however, is not available. I did not install knowingly, any ports exclusive to fetch.. (and I needed fetch initially to retrieve the ports) I believe the command "fetch" is included in the basic install (bare-bones) of FreeBSD 6x.
the code above is a working example of how to use "fetch" as an external "connection manager" for TCL.. which, in my opinion, I found to be simpler to set up, and more reliable and less-intrusive in the current application in which I have used TCL coding to achieve.
there
Now, what does my eggdrop DO with all of this?? my egggy does the following:
1.. grabs chat stats and generates them- posts them to my website**
2.. monitors the current state of the cast server- checks which input mount is active and passes this data to the output compiler.
3.. Takes said output and generates the appropiate webpages
4.. updates channel topic and displays song/stream/dj info to the chatroom.
5.. RECORDS the stream and then makes it available for immediate download; 'instant podcast'. (admin controlled)
6.. monitors and CONTROLS the local playout (RAC) system- and with active feedback- does NOT "hammer" the RAC or server with blind commands)
7.. "auto play" feature will start/stop the RAC remotely- when a guest DJ logs in (no countdowns and admin kick-start commands nessessary!)
8.. allows preveliged DJ/caster access and AUTOMATICALLY switches them onto the broadcast chain upon login into the server- again, no countdowns or admin-kick commands nessessary.
9.. "master control" input and local studio stream-detect
10.. SMART implementation of active direct-control commands to the RAC by admins and super admins (exclusively)system can detect if the playout is available, which mode is set and if the RAC is available/online and sends messages of the current state to the admin who requested them.
11.. instant update of song/title/DJ info via chatroom commands as well as change-detect and topic/channel stream/title requests.
12.. manages a "bug" in icecast where listener counts are not properly-transferred to the current mount currently online; bug is corrected and the counts are accurately-displayed. (called the "hop detector")
new features in development:
auto-detect and implemation of guest DJs local playout system.. and them to display that in place via RAC channel and not SC channel
auto-timed podcast creation and RSS updating via simple chatroom commands
playlist search and pick lets listeners search out a tune then auto-cue it into the current playing list for airplay.
and many more as I think of them hehehe
-DjZ-
**feature currently disabled while I'm in debugging mode |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
