Ayanir,
If the origin of this problem is losing GSM signal, then you've got
handle Android specific broadcast actions to detect this.
TCP/IP does not detect broken connections if there is no data being sent
- i.e. you only find out that the connection is broken when you try to
send. This is independent of the API - with or without NIO.
Even with poor quality connection you won't randomly lose packets. This
is because you're using TCP, which guarantees integrity and and order
(unlike UDP), retransmitting lost packets as necesary. If that can't be
done (something that TCP can't recover from, like lost GSM signal), then
you'll get a socket write error. So it's either correct data in correct
order, or a broken connection - nothing in between.
However, if the connection is still alive, you data may arrive on the
reading side broken down into differently-sized chunks (compared to what
was written) - so up to your code to break it down into meaningful messages.
-- Kostya
02.06.2010 11:05, ayanir пишет:
Kostya,
I've changed the reading as you suggested and I haven't found any
significant improvement although I do think that you proposal is a
better programing to avoid problems like connection problem which
cause missing packets.
I didn't understand if your implementation with NIO give you better
notification when there is a problem with the socket connection.
my problem is that the socket "thinks" that it is connected and no
exception being thrown even if it was disconnected due to poor network
signal.
how can I detect this on time and open a fresh one?
I'm still trying to figure out how can I use Broadcast intents for the
data connection state - maybe this will help.
On Jun 1, 5:51 pm, Kostya Vasilyev<kmans...@gmail.com> wrote:
Ayanir,
NIO is non-blocking, so it's easier to serve multiple connections from
one thread. Also, NIO is easier to interrupt / shutdown, which I think
is important for an Android app. But other than that, I personally think
it's a matter of taste, since there has to be a worker thread for both
NIO and "old style".
In the code you posted, DataOutputStream should write the entire data
structure, blocking until it does. So with the change on the reading
side (looking for '\0' anywhere) it _should_ already work - have you
tested it yet?
-- Kostya
01.06.2010 17:53, ayanir пишет:
is the NIO works better then the usual Socket?
by works better I mean no freezing.
I have no problem working with NIO if it will make the difference.
ayanir
On Jun 1, 10:55 am, Kostya Vasilyev<kmans...@gmail.com> wrote:
Ah, so those are data streams. Sorry I missed that (using NIO socket
channels here :)
Then you should be ok with packet fragmentation - as long as your read
method checks for '\0' anywhere within the buffer.
-- Kostya
01.06.2010 11:43, ayanir пишет:
Kostya, I did as you suggested and I'm now looking for the delimiter
('\0') on the of the last read buffer and not just the last byte.
I didn't understand how can I check the return value in the write()
method since it is declared as void. is there another way?
--
Kostya Vasilev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com
--
Kostya Vasilev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com
--
Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
