For the first issue, it's about TCP programming paradigm. When your peer socket is closed gracefully, then you can detect it by checking if the return value of "read()" call is 0. When your peer socket is closed abruptly (for example, system power off, even with battery, you can't guarantee a NOTFIY message will reach to your program), then you have no way to detect it immediately (I think this is the issue that bothers you). The common practice to handle this situation is using SO_KEEPALIVE socket option. After you create the socket, you can call "setsockopt" to enable TCP keep alive mechanism on your socket. TCP_KEEPIDLE, TCP_KEEPCNT, TCP_KEEPINTVL are three other options you need to use. Generally speaking, the logic is: when your TCP/IP stack detect your socket is idle for TCP_KEEPIDLE seconds (no message come from peer), then it will send a packet to peer, if no acknowledge is received, then it will re-send another probe packet at a interval of TCP_KEEPINTVL seconds. Once total retry count reaches TCP_KEEPCNT, TCP/IP stack will assume peer is closed and it will notify your program. You can tune these parameters to make your program react quickly when peer is powered off.
Regarding the 2nd issue, there is a property named "delayoff", once sleep timer is enabled, it will notify the App every one minute. If sleeper time is cancelled or fired, this property will be changed to 0.