[SOLVED!] here we go again.. SOCKETS!

[dj-zath]

hi everyone, speechles and nml! I hope everyone is doing well!

I'm Baaaaaack!!

I got an new one to knarl on...

over the summer, I have received an LED marquee sign to put up on the wall and have song titles and stuff displayed...

I also was running a WINDROP (this is an important issue later) locally that sat in a ustream chatroom and via using simple commands, I was able to control the LED marquee sign through a serial port.. that part, was a PIECE OF CAKE!

and although this little thingy worked, it was *NOT* able to receive SERVER updates from the streams... only local calls to the playout system that ran on the same machine locally... this presents a few problems..

1).. only updates from the playout directly can be entered and
2).. they had to be entered manually..

NOW, I want to do this automatically AND have it read from the Cast servers... and lone-behold! here we go with the sockets and http module.. it won't work in a windrop! (I assume this is because none of the globals will migrate to child procs inside other procs.. not to mention, I had other problems with modules where I had to remove all the linefeeds and replace them with "windows line returns" in order to get them to load- and I assume this is because there are no cygin support modules for http and tk modules)

that or I simply don't have the cygin versions of http (I couldn't find one anyhow)

anyways.. so I have been TRYING to pull this little stunt off.. with NO luck!

I guess what I'm saying is I need a working socket of some sort.... when in unix, theres no problem! I can even do auth sockets.. but I can't get ANY of that to work in the WINDOWS command shell (where the windrop lives) at all!! the casting system uses windows- and thats my problem there.. perhaps, a simple http-get program that DOES NOT require .NET framework would work VERY nicely.. I could not find such an animal (not for free, anyways)

so, I'm rather STUCK!

to recap, I can't get the HTTP module to work in windows because there's no cygin support modules that it requires to function... and I can't use any third-party "http get" programs because I can't find any... I can get a native socket to work- sorta, , however, the server returns "bad request" or "function not implemented" errors... (or nothing at all!)

any ideas would be greatly-appreciated!

I don't really have any code to paste or show at this time since it wouldn't make sense anyways.. but to explain, the idea was to have 2 bots- one that sits on the local box as a "relay" (and a simple greeter for a unused/old chatroom) while the main bot that sits in a datacenter a 1000 miles away, runs the show.. the "main" bot receives '!sign' commands in the current chatroom (on an entirely different network) and then relays them to the webserver in the same network.. this results as a simple webpage of XML strings that the "relay" bot can then fetch from the webserver and then, translate the strings into the commands for the marquee.. then, when using an "exec" command to pass the strings via stout, right to the control interface program for the sign... thats how it works! the problem is I can't get the relay bot to properly communicate with ANYthing, webserver or the other bot while using a native socket or the http module (the http module is riddled with errors when I try to load it in the windows envirement, yet it works FINE in FBSD... )

perhaps another method would be a BOTNET.. but that sounds messy at best! (I haven't tried a botnet yet)

anyhow that's my current "can of worms" I got open at the moment!

I hope everyones doing well- and thanks to anyone in advance for any help and/or suggestions (I CAN also offer demos of this thing.. if anyone needs to see it for the concept)

again, thanks and happy holidays!

-DjZ-

[nml375]

Globals migrating to a child process? I think you really need to differentiate between environment variables (which is the only thing inherited by child processes - regardless of the platform) and application data (such as variables in tcl). To be honest, I don't see why any of this would be related to your issue...

Tcl is a newline-terminated language, so obviously any tcl-script better conform to the local newline/linefeed behavior.

By cygin, I assume you're referring to cygwin? Would this be a complete cygwin environment, or just a precompiled eggdrop ("windrop") with the needed cygwin libraries included? In the latter, you obviously don't have any of the tcl packages (such as http).

As for cygwin and tcl.. Just don't use cygwin's tcl-package whatever you do. It's antique and broken. Get a recent tarball from www.tcl.tk and build/install it the oldfashioned way - by the way, while you're at it, get the eggdrop source and build it against your brand new 8.5 tcl libraries...

that or I simply don't have the cygin versions of http (I couldn't find one anyhow)

No, what you are lacking is a proper installation of tcl

anyways.. so I have been TRYING to pull this little stunt off.. with NO luck!

I guess what I'm saying is I need a working socket of some sort.... when in unix, theres no problem! I can even do auth sockets.. but I can't get ANY of that to work in the WINDOWS command shell (where the windrop lives) at all!! the casting system uses windows- and thats my problem there.. perhaps, a simple http-get program that DOES NOT require .NET framework would work VERY nicely.. I could not find such an animal (not for free, anyways)

If you are using a cygwin environment, and you insist on using an external application, why not use curl?

so, I'm rather STUCK!

to recap, I can't get the HTTP module to work in windows because there's no cygin support modules that it requires to function... and I can't use any third-party "http get" programs because I can't find any... I can get a native socket to work- sorta, , however, the server returns "bad request" or "function not implemented" errors... (or nothing at all!)

any ideas would be greatly-appreciated!

I don't really have any code to paste or show at this time since it wouldn't make sense anyways.. but to explain, the idea was to have 2 bots- one that sits on the local box as a "relay" (and a simple greeter for a unused/old chatroom) while the main bot that sits in a datacenter a 1000 miles away, runs the show.. the "main" bot receives '!sign' commands in the current chatroom (on an entirely different network) and then relays them to the webserver in the same network.. this results as a simple webpage of XML strings that the "relay" bot can then fetch from the webserver and then, translate the strings into the commands for the marquee.. then, when using an "exec" command to pass the strings via stout, right to the control interface program for the sign... thats how it works! the problem is I can't get the relay bot to properly communicate with ANYthing, webserver or the other bot while using a native socket or the http module (the http module is riddled with errors when I try to load it in the windows envirement, yet it works FINE in FBSD... )

I thought you said you couldn't find any http-package for your windrop?

perhaps another method would be a BOTNET.. but that sounds messy at best! (I haven't tried a botnet yet)

anyhow that's my current "can of worms" I got open at the moment!

I hope everyones doing well- and thanks to anyone in advance for any help and/or suggestions (I CAN also offer demos of this thing.. if anyone needs to see it for the concept)

again, thanks and happy holidays!

-DjZ-

Also, posting the same query three times does not help... I've sent the other two to the junk yard...

[dj-zath]

Hi nml! and thanks for the quick response!

I hope you are in good health and spirits!

first off, the multiple postings was a accident, when I initially pushed the post button, nothing happened.. I mean everything was FROZEN for a good 5 minutes (at least)! so I got up and went to the kitchen.. when I came back, I still saw no postings, so I tried the "preview" and "post" buttons again and still there was no response.. when a post finally did appear (a good 5 minutes later from the second time I pressed the button) I did stick around a few more minutes to make sure dupes didn't occur, but apparently they did after I left.. again, sorry for that; it wasn't intended..

[QUOTE = nml375]Tcl is a newline-terminated language, so obviously any tcl-script better conform to the local newline/linefeed behavior. [/QUOTE]
[QUOTE = nml375]As for cygwin and tcl.. Just don't use cygwin's tcl-package whatever you do. It's antique and broken.[/QUOTE]

... and theres the source of my problem right there!

and yes, I DID mean Cygwin (I'm an idiot! hehe)

Windrop came as a pre-compiled "zipfile" so I merely unzipped it and put it in place.. there is an http module in the set, but, as you said, its old (2001!) and broken.. what I also meant to say was I couldn't find the TK version of TCL modules that were pre-compiled for the Cygwin environment.. there IS a tcl8.5.dll in the package, though.. so I figured that was more recent and it appears to be working (to some degree) and the problem I was mentioning earlier about "globals", I should have said " the globals variable doesn't work properly since any child procs won't receive the mother proc's variables"

example:

Code: Select all

proc  mother {} {
        set var1 "something"
        proc child {var1} {
              putlog "var1"
        }
}

-or-

Code: Select all

proc  mother {} {
        set var1 "something"
        proc child {} {
        global var1
              putlog "var1"
        }
}

the problem is that "var1" won't migrate to the child proc.. that's what I was trying to explain. furthermore, it seems to be determined at how far "down the chain" its being called from as well.. the global parameter DOES work from the master down to the second level, but not any further.

BUT

You called it- the problem is the package is old and useless/broken so that kinda buries the whole project! (re)compiling tcl8.5 (or the entire eggdrop altogether as you recommend) isn't going to solve the issue, I'm afraid.. certainly won't be easy to do.. the reason is because the machine that its installed on is EMBEDDED and windows has to be "customized" in order to work on that machine.. I thought I could simply stick the windrop on it and "go to town" and, for the most part, I was successful.. however, this didn't mean actually installing libs, and having to compile another environment without a shell to work in!

all-in-all you have answered my query, thanks!

The answer will either be trying to use a third-party "ports management" (or "http get") program thats simple and doesn't require Microsoft .net framework (or Java) to be installed (can't install .net or Java because MMC isn't available in this version of windows; think of it as trying to install an eggdrop on a tablet using the tablet's native OS!)

or

perhaps a botnet (partyline) where I can have the xml strings sent over, oh wait.. I can't do that! the bots are on 2 seperate networks and don't share a common chatroom at all! (if they did, it wouldn't be an issue to have 2 bots)

.,.. or maybe I CAN...

I donno.. I'm running out of time (as usual) so perhaps I'll put this to bed until I can figure out a way to compile a new and full-blown version of eggdrop, along with all its necessary modules and packages.. on an embedded version of Windows without the use of MMC or the Windows installer (msi handlers).

and before you ask, why this all is.. the machine that this is all put on is an old Google GIPX system.. its powerful, but was designed for unix- not Windows.. and Windows does NOT like it AT ALL, probably because it has no beefy video capabilities, NONE! and putting in a video card is out of the question since there's only one slot- and that gets a -ready for this- video cap card! the system is meant to "act like *nix" and run unattended without an keyboard mouse or monitor.. or SHELL; It also is driven hard since it has to render broadcast quality video @ 60 fps!
(its basically a broadcast video transmitter) Windows is used because the FMLE doesn't come in *nix flavors.. so I had to "come up with a solution"- Windows modified to not rely on the GUI and not have to be babysat! All was good, even WITH an eggie on it, until I had to have the eggdrop open a socket and extract some data!

oh well, back to the drawing board..

-DjZ-

[nml375]

No worries, just letting you know the duplicates went straight to the junk yard..

If you are using the "windrop" zips, you don't have a full cygwin environment, which explains why you are lacking all the usual stuffs. As you observed, they've simply packed the needed dll's with the eggdrop binary, and left all else out.
This is one of the reasons why I generally recommend compiling eggdrop yourself under a cygwin environment if you really need to run eggdrop on a windows host (there are other reasons too, such as windows ASLR - which can mess things up badly).

Next, when you spoke of childprocs, I assumed you were talking of processes. The reason for this is: There is no such thing as a child proc in tcl. A proc is located in a namespace (the global namespace :: if no other is specified), and is created using the proc command.
Yes, you can issue the proc command from within a proc, but that does not make the newly created proc nested or related with the previous one. In fact, once the calling (previous) proc ends (returns), the newly created proc will in fact persist.

the problem is that "var1" won't migrate to the child proc.. that's what I was trying to explain. furthermore, it seems to be determined at how far "down the chain" its being called from as well.. the global parameter DOES work from the master down to the second level, but not any further.

Sorry, but this is just bonkus. The global command simply links a local variable with a globalspace variable with the same name. It does not care from which level it is invoked, apart that invoking it from a globalspace level really is a no-op (the "local" variable would already be the globalspace one as we're at the globalspace level). Even if you were to use the upvar command, which can traverse to a specific level in the call-chain; you can't traverse downwards - only upwards to the calling procs...

I believe I've told you this many times before; Forget everything you ever learned about php, java, c++, etc when coding tcl. Really!
Tcl is not object oriented.
You can't nest functions (procs).
There is no inheritance of variables.
You can't pass arguments by reference (you can use upvar and global to access variables in already-existing environments in the current call-chain, though this requires good knowledge in tcl's spaces).

You called it- the problem is the package is old and useless/broken so that kinda buries the whole project! (re)compiling tcl8.5 (or the entire eggdrop altogether as you recommend) isn't going to solve the issue, I'm afraid.. certainly won't be easy to do.. the reason is because the machine that its installed on is EMBEDDED and windows has to be "customized" in order to work on that machine.. I thought I could simply stick the windrop on it and "go to town" and, for the most part, I was successful.. however, this didn't mean actually installing libs, and having to compile another environment without a shell to work in!

I don't suppose you can use the Terminal Services Core for your Headless build?

... Windows is used because the FMLE doesn't come in *nix flavors..

I don't suppose you can run the FMLE software using Wine?

[dj-zath]

I solved it!

here's HOW I did it...

and no- it didn't require me having to (re)install anything..
couldn't do that on an embedded system anyways

below is just the socket and sign interface code; what I have omitted is the bot IRC and greet stuff (which you all know anyways).

note that although this bot sits on an irc channel (on Ustream), as far as the sign interface code goes, it doesn't do anything.. the bot merely "greets and then gives a link to a different chat network"; this code runs on its own.

this code below runs independent to the bot, by monitoring a specific webserver for a file that it opens a socket to.. the bot will change, update, clear or activate the sign based on code instructions given in the file that it retrieves.

Clever, huh?

Code: Select all

proc	GetInfo {} {
	global SignIP SignPort SignErr DetSW RawInfo SignInfo; 
	if {([catch {set Sock [socket -async $SignIP $SignPort]; fconfigure $Sock -blocking off -buffersize 10; fileevent $Sock writable [list Put $Sock];}])} {
		incr SignErr; 
		if {($SignErr == "2")} {
			set DetSW "0"; 
			set RawInfo ""; 
			set SignInfo ""; 
		} elseif {($SignErr > "2")} {
			set SignErr "3"; 
		}; 
	} else {
		set SignErr "0"; 
		set DetSW "1"; 

 		proc Put {Sock} {
       global Csh01 SignIP SignPort RawInfo; 
       if {($Csh01 != "1")&&(![catch {set Csh01 "1"}])&&(![catch {puts $Sock "GET /SignInfo.xml HTTP/1.1\r\nUser-Agent: Mozilla 5.0\r\nHost: ${SignIP}:${SignPort}\r\nConnection: close\r\n\r\n\r\n"; set RawInfo "";}])} {;} elseif {($Csh01 != "0")&&(![catch {set Csh01 "0"}])&&(![catch {fileevent $Sock writable ""; fileevent $Sock readable [list Get $Sock]; flush $Sock;}])} {;};
       }; 

	        proc Get {Sock} {
       global RawInfo; 
       if {([eof $Sock])||([fblocked $Sock])} {close $Sock;} elseif {(![eof $Sock])&&(![fblocked $Sock])&&(![catch {gets $Sock data; append RawInfo $data;}])} {;};
       }; 

		set VarA [string first "\<on\>" $RawInfo]; 
		set VarA [string range $RawInfo $VarA [string length $RawInfo]]; 
		set VarB [string first "\<\/on\>" $VarA]; 
		set VarB [expr $VarB - "1"]; 
		set VarB [string range $VarA "4" $VarB]; 
		if {($DetSW == "1")&&($VarA != "")&&($VarB == "onair.gif")} {set DetSW "1";} else {set DetSW "0";}; 

		set VarA [string first "\<sign\>" $RawInfo]; 
		set VarA [string range $RawInfo $VarA [string length $RawInfo]]; 
		set VarB [string first "\<\/sign\>" $VarA]; 
		set VarB [expr $VarB - "1"]; 
		if {($DetSW == "1")} {set VarB [string range $VarA "6" $VarB]; set SignInfo [subst -nocommands -nobackslashes -novariables $VarB];} else {set SignInfo "";}; 
	}; 
	return "0"; 
}; 

proc	SignOut {} {
	      global DetSW Csh02 SignInfo; 
	      if {($DetSW == "1")&&($Csh02 != "$SignInfo")&&($SignInfo != "")&&(![catch {exec betacom.exe com1 [subst -nocommands -nobackslashes -novariables $SignInfo] 2>@1;}])&&(![catch {set Csh02 "$SignInfo";}])} {;} elseif {($DetSW == "1")&&($Csh02 != "$SignInfo")&&($SignInfo == "")&&(![catch {exec betacom.exe com1 2>@1;}])&&(![catch {set Csh02 "$SignInfo"}])} {;} elseif {($DetSW != "1")&&($Csh02 != "$SignInfo")&&(![catch {exec betacom.exe com1 2>@1;}])&&(![catch {set Csh02 "$SignInfo"}])} {;
         }; 
	      return "0"; 
}; 

("betacom.exe" is the name of the sign interface program)

This little beastie sits on the machine that the sign connects to directly; its also my embedded video streaming system which sits in the racks without a mouse, monitor or keyboard..

at the time of this writing, I still have to write the "other" end on the main server... but all initial tests are VERY promising and this little jewel is fast and doesn't bind,slow down or tie up the machine or network in any way..

[nml375]

A few comments here...
It is very ill-advisable to create file-events calling procs prior the proc being created itself. And I still don't see why you insist on nesting procs - it only creates race-issues where you cannot be certain a proc is created or not upon the time of calling it. The only thing that saves you here, is the fact that eggdrop only uses one tcl-interpreter (and thus is pretty much single-threaded).

Having empty if/elseif/else-bodies makes the logic of the code that much harder to follow.

subst -nocommands -nobackslashes -novariables is pretty much a no-op; That is, there will be no modifications of the string argument, and just clutters up the code impairing readability.

Your seemingly random use of catch suggests that the workflow is not well-thought. There is no reason what so ever to catch a line of code such as this:

Code: Select all

set Csh01 "0"

Neither does it make much sense in this part:

Code: Select all

	if {
		($DetSW == "1") &&
		($Csh02 != "$SignInfo") &&
		($SignInfo != "") &&
		(![catch {
			exec betacom.exe com1 [subst -nocommands -nobackslashes -novariables $SignInfo] 2>@1
		}]) &&
		(![catch {
			set Csh02 "$SignInfo"
		}])
	} {
		
	} elseif {

The only reason why "set Csh02" would throw an error, would be if SignInfo wasn't set. However, if it wasn't set, the (uncaught) test ($Csh02 != "$SignInfo") would throw an error and the set-command would not be executed in the first place.

Looking then at your parsing logics, this makes no sense:

Code: Select all

		if {
			($DetSW == "1") &&
			($VarA != "") &&
			($VarB == "onair.gif")
		} {
			set DetSW "1"
		} else {
			set DetSW "0"
		}

Set DetSW to 1, if and only if DetSW already is set to 1?

After all this ranting, I took the liberty of re-writing your code somewhat:

Code: Select all

proc SignOut {} {
	if {[info exists ::signData]} {
		set start [string first {<on>} $::signData]
		set end [string first {</on>} $::signData]

		if {[string match {*onair.gif*} [string range $::signData $start $end]]} {
			set start [string first {<sign>} $::signData]
			set end [string first {</sign>} $::signData]
			set line [string range $::signData $start+6 $end-1]

			if {![info exists ::displayText] || ![string equal $::displayText $line]} {
				if {![catch {[exec betacom.exe com1 $line 2>@1]} output]} {
					set ::displayText $line
				} else {
					putlog "Error calling betacom.exe: $output"
				}
			}
			
		} else {
			catch {[exec betacom.exe com1 2>@1]}
			unset ::displayText
		}
		
	} else {
		catch {[exec betacom.exe com1 2>@1]}
		unset ::displayText
	}
}

proc readSocket {socket} {
	gets $socket text

	if {[eof $socket]} {
		close $socket
		append ::signData $text
		SignOut
	} elseif {![fblocked $socket]} {
		append ::signData $text
	}
}

proc writeSocket {socket} {
	fileevent $socket writable {}
	fileevent $socket readable [list readSocket $socket]
	puts $socket "GET /SignInfo.xml HTTP/1.1\r\nUser-Agent: Mozilla 5.0\r\nHost: ${::SignIP}:${::SignPort}\r\nConnection: close\r\n\r\n\r\n"
	flush $socket
}

proc GetInfo {} {
	unset ::signData
	if {[catch {socket -async $::SignIP $::SignPort} socket]} {
		#We were unable to create the socket, log the error:
		putlog "Failed opening socket: $socket"
	} {
		fconfigure $socket -buffering line
		fileevent $socket writable [list writeSocket $socket]
	}
}

Edit: Fixed issue with reading SignIP and SignPort as local variables in writeSocket

[dj-zath]

hi nml and thanks for the feedback (and for rewriting this code hehe)

as a lark I shall try it and see how it performs

(I don't remember you being so "ranty" in the past heheh)

first off, I have to explain a a few things...

about the "error detect" section- its actually from another piece of code I used for "exec" running fetch.. and the likeliness of a MISSING socket or connection.. admittingly, I DO know it will never read an error state with an async socket

I don't know what the "::" stuff in the variables are for, I have seen them in a lot of code here, on the forum, and thought they were "a new way of doing things".. my methods are from "old school" TCL coding... (we're talking 90s!)

what's also not mentioned is that I have a proc called "SetVars" which sets up all the variables and namespaces that runs at the start of the first loop.. this runs 10 seconds from eggdrop start, but the other loops run 30 seconds after eggdrop start. the idea is that all the variables are established before the main loops run and you're right- if can get some serious racing issues if I didn't do it this way...

the code is hard to follow, but I can follow it since I'm used to it.. its not the correct way, but it seems to save cycles and seems stable when considering many scripts that I have tried from others which will lag, tie up, eat RAM or the CPU like candy and/or cause the eggie to fall off IRC... none of my code will cause these conditions

and lastly...

To be honest, I'm just "winging this stuff".. I really don't know what I'm doing- its all trial and error.. I would take working examples and take them apart and try to understand how it all works...

I do this because I can't get any "pros" do help me out.. I need specific things, and there aren't any "free and working" code out there for these tasks.. in the end, I get results.. perhaps not the BEST results.. but I at LEAST try to keep it bloat-free and clean.. even though it might not make any sense..

there

thanks for the code rewrite; I will pop it on that box and see what it does.. assuming I don't need any special or additional modules to load it... (again, I can't recompile anything on that system because it's windows CAN'T install anything or compile) I'll also take it apart and learn how its elements work, so I can gain a working understanding on what you have done and what steps toy have done to make it work.. stuff from a bad server/dead sockets to timing issues!

perhaps I should send you the main bot itself.. and see if you would like to rewrite that pig heheh it certainly would be a challenge!

I'll report back my findings!

AND...

I hope you're doing well.. perhaps the rants are from having a bad day?

take care and, again, thanks for the feedback!

-DjZ-

[nml375]

Hope you don't take this the wrong way, as the main idea is to give you hints on improvements (not making you feel like it's the worst script ever written).

The ::-stuff is the namespace separator in tcl introduced in tcl 8.0 (released in August 1997). A globalspace variable myVar would have the fully-qualified name ::myVar.
I personally prefer the FQN to using the global command, as I always kept forgetting to add variable names to the global-command of each proc; or I'd add variables I didn't use, resulting in a name conflict later on. Also, I can instantly see whether a variable is a localspace or a globalspace one..
To the point though, in this case, there's no real right or wrong way. Both works pretty much equally well, and mainly comes down to your coding-style.

Variable setup part:
Since you apparently have external dependancies of the global variables used here(?), might be best to advice that I dropped some of the variables in my re-write, that seemed redundant or unused. As I made a re-write from scratch, some globals also has changed their names.
Csh01 - Removed. Appears only to control whether to send the http request or not in Put
DetSW - replaced by checking for existance of ::signData and presence "online.gif".
SignErr - replaced by logging the error using putlog. Could rather easily be restored if used to prevent hammering.
RawInfo - seems I renamed this ::signData
SignInfo - seems I renamed this ::displayText
Csh02 - Removed. The previously set displaytext is already stored in ::displayText. The text yet to be sent never goes into a global variable (local variable line within SignOut).

[dj-zath]

oh! that might explain why it didn't work (just kidding heheh)

hi nml! I hope you're in good health and spirits..

I didn't get a chance to try it out, actually.. but in fairness, I probably should explain what the variables do

Csh01 - Removed. Appears only to control whether to send the http request or not in Put

see the explanation for Csh02...

DetSW - replaced by checking for existance of ::signData and presence "online.gif".

DetSW actually checks to see if the "studio" is online, since if theres no studio online, then theres no point to updating a sign that noone can see to read! DetSW is read from the sign code so that even if the last webpage is there, but the studio isn't, the sign will then go blank, yet retain its last entered data upon restart.

SignErr - replaced by logging the error using putlog. Could rather easily be restored if used to prevent hammering.

this varable is an "error count"; the idea was that when the socket returned nothing (seems to happen a lot on Comcast) or when the bot polls the local playout server, the connection fails.. and the code that "didn't make sense" to you eariler, is actually a "cache and count controller" what it does is prevents a dead socket from being detected in a count of X number of turns (or loop cycles) from causing the bot to reset the playout data from on to off to on to off, etc... the code counts 5 cycles and, if after 5 cycles will THEN report the socket has failed while in the meantime, will cache the result from the last successful read.

in short, this prevents a racing condition from a flaky connection.

RawInfo - seems I renamed this ::signData

Rawinfo exists cause it seems I needed it to write TO SignInfo.. calling a write to SignInfo directly woudn't work!

SignInfo - seems I renamed this ::displayText

noted.

Csh02 - Removed. The previously set displaytext is already stored in ::displayText. The text yet to be sent never goes into a global variable (local variable line within SignOut).

Csh01 and Csh02 are used as "change detectors" they prevent hammering of both the connection and the update, for example, otherwise the sign would keep RESETTING after every cycle!

they are globals since they needed to "remain" so that they can be compared at the next time the loop runs

and there ya go!