Home AMX User Forum NetLinx Studio

Close Sockets on Reboot

Is there a method to close IP Sockets on Controller Reboot?
I mean before it shuts down, not after if has already rebooted.

My Sharp TV doesn't let go, and then won't reconnect without a Physical Power Cycle - which can't be good for it...

Comments

  • ericmedleyericmedley Posts: 4,177
    If it's an unplanned reboot not really. I suppose you could rig up an UPS that could hold the power on and then do an emergency socket close when you detect a power outage.
  • You could also open a socket just to send the command, and then close it after you get a reply.
  • ericmedleyericmedley Posts: 4,177
    ^^ This!

    (And some stuff to make the post long enough)
  • alecgalecg Posts: 30
    I'm just used to working with hardware platforms that recognize when software is being pushed / updated, and allow the programmer / developer to properly close ports before completing the push.

    Any idea how to force a device with an open port closed without requiring a hard power cycle?

    The darn thing won't even let me putty into it - "Remote connection closed by host"...
  • ericmedleyericmedley Posts: 4,177
    alecg wrote: »
    I'm just used to working with hardware platforms that recognize when software is being pushed / updated, and allow the programmer / developer to properly close ports before completing the push.

    Any idea how to force a device with an open port closed without requiring a hard power cycle?

    The darn thing won't even let me putty into it - "Remote connection closed by host"...

    Well, to reiterate, why not just open the connection, send the command, then close it? I do this and there is no noticeable delay in performance.
  • a_riot42a_riot42 Posts: 1,624
    alecg wrote: »
    Is there a method to close IP Sockets on Controller Reboot?
    I mean before it shuts down, not after if has already rebooted.

    My Sharp TV doesn't let go, and then won't reconnect without a Physical Power Cycle - which can't be good for it...

    Sounds like the Sharp TV is in a TIME-WAIT state. I think AMX closes all sockets when a reboot command is received. Pulling power obviously is a different story. The TV is waiting for a signal to end the TCP session that is never going to come so it has to timeout. I don't know what the timeout is on those devices and its likely not configurable. 4 minutes is what the RFC says for TCP. Like others have said, its better to close the port when you don't need it to avoid this kind of thing.
    Paul
  • alecgalecg Posts: 30
    Eric,

    I'm using a Duet Module. Why would the (far more advanced than me) guy / gal who wrote that module fail to close the connection after a command is sent? Maybe because they are polling for device change status (e.g. and user picks up the handheld and changes the mute state)? Not sure, but I've seen threads where people are yelled at for opening sockets just long enough to send a command and then closing them again.

    Paul,

    It's exactly that (Wait for Timeout) but you'd think AMX would close the ports on a software push. If I hard power cycle the device, I agree all bets are off, but on a reboot? That seems pretty rudimentary. Why wouldn't there at least be a method to develop this manually?

    Thanks guys for the responses, either way. Constantly learning and all...! Maybe someone from AMX will read this a think to themselves... "um, yeah, why AREN'T we doing this?"
  • a_riot42a_riot42 Posts: 1,624
    alecg wrote: »
    Eric,

    I'm using a Duet Module. Why would the (far more advanced than me) guy / gal who wrote that module fail to close the connection after a command is sent? Maybe because they are polling for device change status (e.g. and user picks up the handheld and changes the mute state)? Not sure, but I've seen threads where people are yelled at for opening sockets just long enough to send a command and then closing them again.

    Paul,

    It's exactly that (Wait for Timeout) but you'd think AMX would close the ports on a software push. If I hard power cycle the device, I agree all bets are off, but on a reboot? That seems pretty rudimentary. Why wouldn't there at least be a method to develop this manually?

    Thanks guys for the responses, either way. Constantly learning and all...! Maybe someone from AMX will read this a think to themselves... "um, yeah, why AREN'T we doing this?"

    I would not be surprised at all if Sharp's TCP implementation is not standard, or just has bugs and isn't doing what its supposed to do. They are not known for having robust control.

    If the module is polling the device for status it still doesn't need to leave the TCP connection open, although there isn't anything wrong with doing that per se. TCP connections can last for hours/days as in telnet, FTP etc. But when the client goes down, the other side of the connection is supposed to timeout and then close the socket within a few minutes, which might not be great for controlling a TV. Unfortunately the Sharps only listen to one port, so you can't restart the session on another port. I use serial for TVs, since IP can be tricky with your average device's kludgy firmware.
    Paul
  • GregGGregG Posts: 251
    a_riot42 wrote: »
    Unfortunately the Sharps only listen to one port, so you can't restart the session on another port.

    One port is really all it should need to listen on. My web server at home only listens on port 80, but can handle 1000's of simultaneous connections.

    So I'd really blame the Sharp for not listening for multiple incoming connection attempts. It's _SO_ non-standard that you'd have to write a custom IP stack to ensure that you weren't able to serve the second connection attempt.
  • a_riot42a_riot42 Posts: 1,624
    GregG wrote: »
    One port is really all it should need to listen on. My web server at home only listens on port 80, but can handle 1000's of simultaneous connections.

    Sorry, I meant listen from. Two incoming connections from different ports to its port will not be serviced.
    Paul
  • DHawthorneDHawthorne Posts: 4,584
    alecg wrote: »
    Eric,

    I'm using a Duet Module. Why would the (far more advanced than me) guy / gal who wrote that module fail to close the connection after a command is sent? Maybe because they are polling for device change status (e.g. and user picks up the handheld and changes the mute state)? Not sure, but I've seen threads where people are yelled at for opening sockets just long enough to send a command and then closing them again.

    Paul,

    It's exactly that (Wait for Timeout) but you'd think AMX would close the ports on a software push. If I hard power cycle the device, I agree all bets are off, but on a reboot? That seems pretty rudimentary. Why wouldn't there at least be a method to develop this manually?

    Thanks guys for the responses, either way. Constantly learning and all...! Maybe someone from AMX will read this a think to themselves... "um, yeah, why AREN'T we doing this?"

    All bets are off if it's a Duet module. Some of those were just badly written. My personal pet peeve was a Sirius tuner module that auto-tuned you to the demo channel any time it detected a sat signal loss. So, any reception glitch on the antenna, bang, channel change. It's not like the demo channel actually *works* if the antenna really is out, why ever would you do that?
  • ericmedleyericmedley Posts: 4,177
    Duet Module: Well, if you introduce any other code (particularly a black-box module) all bets are off. There are good modules and there are bad. I am not a big fan of modules written by AMX for IP communications since I feel they seem to assume you always want to hold open an IP connection even when you don't. I've always wished they had as part of their API the ability to manage the comm. There are obviously times when you need to keep the socket connected but I don't feel this is one of them.

    But, at any rate, this is not a complicated protocol. If I were in your shoes, I'd just roll my own comm module and make it the way you want. I would also follow Dave's advice and kill the socket once I'd sent the command. Most displays nowadays don't give you all that much (if any) feedback as to what they're doing anyway. I've been treating displays as TOADs for the past 8 years and have to date had no issues with the box not doing as expected.

    But, that's just me.
Sign In or Register to comment.