[Rxtx] Data loss in high ratio while reading event based with SerialPortEvent.DATA_AVAILABLE

[Beyefendi]

In my first post, I had sent my code. Below, I took a part of it.
code-block-1//byte[] buffer = new byte[is.available()];String buffer;while (is.available() > 0) {	//is.read(buffer);	buffer = br.readLine();
When I started to develop this program, I was reading with is.read(buffer). As you know, this method, reads what is available. I've mostly never read a complete packet in one read with it. So, I had to combine the packet parts. I was doing combination with string concatenate like lackingPacket += packetBut this operation made lots of errornous packets.I had to change my reading style.When I came across with this comparision http://recursor.blogspot.com/2006/09/bufferedreader-vs-inputstream.htmlI commented out two lines that are interested in InputStream and tried BufferedReader.Another advantage of BufferedReader over InputStream is that BufferedReader reads until to see new line character (carriage return)So this feature saved me from combination operation.Now, "else if" block in code-block-2 that is below, almost never runs.So more reliable reads occur now. 
Again I took a part of my code that I sent my first post.code-block-2if (packet.length() == 10) {	// packet is fetched in one read
	// .. controls ...	DBOperations.parsePacket(packet.toString());
/*Erskine this is for you: I'm dealing with lackingPacket below */} else if (packet.length() < 10 && packet.length() > 0){ // for is.read(buffer), it cannot read until \n
	// .. controls ...	lackingPacket.append(packet);}As you see, if packet is complete (first if control) sent it to process.If not (else if control), combine it with previous one.Namely, I'm dealing with lacking packet as you see."identifing any complete packets cleanly" is also possible with BufferedReader for me now.
But I want to try your methot that is ByteSink.I goggled and found http://www.docjar.com/html/api/juju/reattore/io/ByteSink.java.html, are you mentioned this interface.
You suggest me decouple it, you said it for "packet parts combination" that I do not do this anymore with BufferedReader because it gives me complate packet usually, or you pointedDBOperations.parsePacket(packet.toString()) call.
I want to take more advices. How are other valuable masters thinking?Thanks in advance.

--- On Tue, 3/29/11, Michael Erskine <msemtd at googlemail.com> wrote:

From: Michael Erskine <msemtd at googlemail.com>
Subject: Re: [Rxtx] Data loss in high ratio while reading event based with SerialPortEvent.DATA_AVAILABLE
To: rxtx at qbang.org
Date: Tuesday, March 29, 2011, 4:26 AM

You're not dealing with any of the bytes that you're sticking into
lackingPacket --  that's where it's all gone!

I suggest you decouple your byte collection from packet processing:
ditch the BufferedReader and identify any complete packets cleanly
from the raw bytes that have been received.

I always use the same pattern with RXTX and I don't encounter any lost
data (the protocols I deal with in the rail industry usually have
packet numbers and checksums and run 24hrs a day so it can be
proven!). My rxtx 2.1.7 helper classes always use the event mechanism
and always read the available bytes with a single call to
java.io.InputStream.read(byte[] b). These bytes are passed directly to
the next stage in the "stack" which is any class that handles incoming
bytes (by implementing a "ByteSink" interface). The serial event then
immediately returns. No looping in the event handler or cluttering it
with byte-stream-to-message-packet juggling! Even for the simplest of
cases it makes sense to follow the OSI 7-layer model!

I use the same ByteSink interface for TCP/IP communications and
occasionally when reading files - any stream of bytes will do.
ByteSink byte handling implementations usually add bytes to an
incoming message buffer and spit out complete messages in whatever
form the protocol demands (usually added to a thread-safe queue of
validated message objects to be handled at leisure). Any message
timeouts and specific replies/acks/naks that required by the protocol
are handled completely separately.



Michael Erskine.
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20110329/5daba748/attachment-0507.htm>