Close Sockets on Reboot
alecg
Posts: 30
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...
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...
0
Comments
(And some stuff to make the post long enough)
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.
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
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
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.
Sorry, I meant listen from. Two incoming connections from different ports to its port will not be serviced.
Paul
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?
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.