ajish.raju wrote: »
Thanks for the information. Didn't learn any of this in class . Regarding reconnecting, if the server is offline for some reason, is there an issue to keep trying to reconnect immediately and so forth.
ajish.raju wrote: »
Is the wait periods between reconnecting due to fact that the processor may go offline due to the load of trying to reconnect or since its futile to reconnect always.
1) it's the kind of connection where I do indeed need the unsolicited feedback to function. (Such as media servers, lighting/security/HVAC/Access systems/etc...
2) I really need constant verification of the dyear vice status.
3) the device is mission critical and can/will be controlled from other systems or from its own UI.
Otherwise it's just white noise. Things like TVs controlled by IP I will let go. I tend to treat them like IR devices. Many times they are really web controlled devices anyway and the connection is closed automatically.
The down side to this is it may take a bit longer to pull all the status needed to bring a UI up to date and you won't know of connection issues, device or network issues until some one tries to use it which may be months since it was last used and maintaining the connection might mean the issue could have been resolved before the client decided to use it again.
Absolutely not. In fact, I'd call that a good practice. My usual method to manage this is to start a timeline when you loose a connection to start attempting to reconnect. I tend to step the attempts down as time goes by. So, for example, at first I might ping the thing quite often and then increase the wait periods after several failed attempts. During that time I may or may not also warn the client and/or myself that such-and-so box went offline and hasn't come back since.
But, I don't think I'd ever just give up and quit trying. otherwise, you will have to restart the system once whatever it is eventually comes back online.
No, it's more of a real-world occurance thing. I know this statement is vague. Let me explain...
In my experience, devices that fall offline tend to do so for the same reasons. It may be that Box A has a tendency to not like being pinged a lot. It's internal processor gets bogged down. But, Box B just has a flaky NIC card that causes it to drop offline for no apparent reason. While Box C doesn't like the way I/AMX talks to it and drops the connection for whatever reason. Or, it's sometjhing goofy I'm doing in code. The possibiblities are endless.
So, what I do is kind of setup a reconnect routine that tries to handle the specific issue. If, for example, I'm dealing with my example of Box A which doesn't like to be pinged over much. I build in an adjustable ping rate that I can tweak on the fly. I might start at 2 seonds between pings. If it misbehaves I'll scale it back to 3 seconds, 4 seconds, etc.. until it finds a happy place. If that device goes ofline, I'll automatically scale the ping rate back and watch it to see if it likes ping_rate+1 better. If the rate gets too slow for use then I know I've got bigger troubles.
If I'm dealing with a box that locks up and/or reboots itself, I may dleiberately wait 2 minutes begore tyring to reconnect to allow time for it to reboot, then start pinging it every 5 seconds afterward. If after, say, 10 minutes I still haven't gotten a response, I know I've got bigger problems and need to come look at it.
All this kind of thinking is built into my routines for maintaining the connection. It may be just as simple as ping the stupid thing every 5 seconds and just keep trying. Or it may be fairly complicated if the situation calls for it.
It all depends upon how much you want to do to manatge things.
In my experience, the controller will only try and fail to reconnect so many times, before it basically locks up that IP port. After that, only a full controller reboot will recover the connection. This could be a weakness in my code, but it works great for all the other devices I handle, just not the switches.
That said, I have found that some devices are perfectly happy with being left open all the time, and reconnecting when the connection drops (ReQuest media servers, Pioneer/Elite TVs are an example). Others seem to lock up if you leave the connection open, so it's best to drop it after a period of inactivity, and reconnect when you need to (Marantz/Denon used to be like that, but I couldn't say for sure if they still are ... they work just fine if you treat them that way, and I never bothered to change my method of talking to them).
The bottom line is you have to determine what your device expects, and how it's going to manage the type of communications you are using with it. There is no "one size fits all" in IP communications, though it would be lovely if a standard existed and everyone used it. Be prepared for some experimentation, and by all means schedule for it and allow for it in your project budget unless you are working with a known and tested device.