This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.


For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.

[SOLVED] Back for More - Socket timeout help needed

Help for those learning Tcl or writing their own scripts.
n
nml375
Revered One
Posts: 2860
Joined: Fri Aug 04, 2006 2:09 pm

Post by nml375 »

Proper code...
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:
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: Select all

while {(![eof $PlaySock])} {set PlayInfo [gets $PlaySock];}
NML_375
d
dj-zath
Op
Posts: 134
Joined: Sat Nov 15, 2008 6:49 am
Contact:

Post by dj-zath »

UPDATE!

Code: Select all

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-
:) :)
n
nml375
Revered One
Posts: 2860
Joined: Fri Aug 04, 2006 2:09 pm

Post by nml375 »

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
d
dj-zath
Op
Posts: 134
Joined: Sat Nov 15, 2008 6:49 am
Contact:

Post by dj-zath »

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
Post Reply