IP Client Programming Tips

ajish.rajuajish.raju chief evangelist of favantePosts: 185
I usually keep my client connections always connected and keep reconnecting immediately if any issues. Is there a disadvantage to this method and what is the usual process for reconnecting.

Comments

  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,159
    I tend to only keep the connection alive if it falls into the following categoies.
    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.
  • viningvining X Member Posts: 4,353
    I usually close the socket since 99% of the time no ones using any TPs or using any equipment. For things like media servers I'll connect when a UI goes on page an keep the device connection open as long as a UI is on page or the server is an active source.

    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.
  • ajish.rajuajish.raju chief evangelist of favante Posts: 185
    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.
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,159
    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.

    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.
  • ajish.rajuajish.raju chief evangelist of favante Posts: 185
    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.
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,159
    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.

    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.
  • ajish.rajuajish.raju chief evangelist of favante Posts: 185
    So it depends on the real world occurrence thing than a theory of just connect and reconnect. Thank you all again.
  • fogled@mizzou[email protected] h4x354x0r Posts: 549
    I tend to try to keep all IP connections open all the time. If one drops offline, I do similar stuff in terms of closing the connection, waiting a few seconds, then trying to reconnect again. I get good results for projectors, TV's, audio processors, etc.; I get horrible results on switches (both Kramer and Extron), they tend to drop offline a lot.

    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.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    There is a whole class of devices that work like a web page: you send a request, it sends a response then kills the connection. They aren't common, but they do exist and you have to be aware of them. Keeping a connection open on them will bog your system down considerably because they aren't designed to work that way.

    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.
Sign In or Register to comment.