I recommend one, or a combination, of some approaches that is common in the IP world:

- close the socket deliberately after not sending a user-interactive command for a while, re-opening only when user-interaction is apparent (ie, have a call that you can make in various places so you know interaction occurred and thus the thing is awake

- only keep the socket open for the duration of anything you do (like with http). obviously this will have a latency impact for repeated interactive commands

- implement a keep-alive & retry. any command you send, give up if you don't get a timely response (ie, because pronto is still waiting for the TCP session to fail) and then close/open the socket and try again. you're basically defeating TCP's inclination to try to recover, which it won't if the tivo closed the connection whilst the pronto is asleep. pronto will resend TCP segments, tivo will ignore them because it has no record of the session the pronto is talking about.

Chris.