Yes, that is what i meant... Otherwise, nothing much you can do about this.
On Tuesday, April 2, 2013 6:53:25 PM UTC+3, plnelson wrote:
Just to clarify- when you say add another command, do you mean add a
command to the PC to send to the Android device that it's closing?That
would be
Just to clarify- when you say add another command, do you mean add a
command to the PC to send to the Android device that it's closing?That
would be a good solution but I don't know if I have any control over what
the PC sends.This is the first and only Android/Java device on that
The higher level point is that most of the time there's no such thing
as a graceful close, when you're working with a protocol where a
connection can fail. You need to write your code to be failsafe, in
some sense. Most of the time, the server being closed will just be
indicated by soem byte
What I have learned from my experience with TCP/IP is that connection / session
control should always be achieved over the application protocol. To put it
another way, as others have said already, graceful disconnection should be
signalled using some specific means over your application
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
5 matches
Mail list logo
