I absolutely agree with putting the 'smarts' at the application level instead of relying on various flags and events from the TCP/IP layer. What interested me in this thread was your process / equipment control via the handset. As a safety mechanism, any equipment should go immediately into a 'safe' mode of operation as soon as the handset becomes disconnected (unless it's just a monitor instead of a controller). With timeouts and keepalives, you may not know the socket's been disconnected right away. Is there a chance that the WiFi module on the handset could go to sleep?
The connection should probably be active continuously, and confirmed by both sides with regular status packets. -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
