Inputstream available method | Telit Cinterion IoT Developer Community
July 26, 2016 - 12:04pm, 4733 views
Hi,
I'm using InputStream read() method to read comm connection data.
Since read() method blocks until a data received, it is not efficient way of reading.
I tried available method to prevent code blocking. It works fine as fas I see.
I wonder, how an InputStream knows amount of data ready to read. It is not written anywhere that InputStream has a buffer. Has it?
If there isn't a buffer in it, how it knows amount of coming data?
Thanks in advance.
Hi,
Why you assume there is no buffer in InputStream? In general InputStream is an abstract class, and it's implementation depends on the original resource within which it is used. But in case of CommConncetion there is an internal buffer. You even have available() method in Input stream. You can find description of it in java doc documentation.
In general you can use avaiilable() method if you want to wait for data, but perhaps it would be also sufficient for your scenario to use:
public int read(byte[] b,int off,int len)
Which waits, untill the data is available. You may read more about it also in Java Doc of CMTK (most likely you will find it in "file:///C:/Program%20Files%20(x86)/Cinterion/CMTK/EHS5/WTK/doc/html_impng/index.html")
Best regards,
Michał
Hi Michal,
Thanks for the answer.
You are right, InputStream is an abstract class and it may have buffer.
In this case, CommConnection has a buffer and in Java Doc, there an explanation about "blocking" parameter like below:
If on
, wait for a full buffer when reading.Do you know the buffer size mentioned here.
Hi Euyar,
I normaly have seperated thread for RS232, and inside it loop:
Hope that it helps. To be more efficent there probably should be StringBuffer instead using response = response + (char)ch;
Jure
Hi Euyar,
Generally internal buffers sizes are not specified. This is mainly, because the assumption is that they should not affect API behaviour, so there is no point in considering them. Some of internal buffers are also dynamicaly allocated. In case of serial buffer from my experience I can say it's arround 4096 bytes. I assume you needed this information, so you can decide which size of table to use for reading. In this case you may use this '4096'.
Best regards,
Michał
Jure, thans for commenting.
You are right about using StringBuffer instead of concatenated String(s)
But if you really want to be efficient, first you need to replace read() method with read(byte[]) or read(byte[] b, int off, int len). Using high level read() for each single byte really takes time.
Best regards,
Michał
Hi Michal,
What is the effect of "blocking" parameter of CommConnection then?
What happens if it is "on" and what happens if it is "off" in the application? Which option is better to use and why?
Thanks.
Hello,
Generally the read methods of InputStream always block until input data is available. So if you don't want this behaviour you need to use available() method. As for the "blocking" parameter of CommConnection interface it does not influence this behaviour and I can't see any difference when changing it - I suppose it might be present only for the compatibility reasons.
Regards,
Bartłomiej
Hello Bartłomiej,
Thanks for the answer.
Yes, you are right. Since read method blocks the code execution until a data received, I changed the code. Now, I'm using available() method to check if there is a new data to read or not.
After your comment, I suppose there is a well working buffer mechanism for CommConnection and blocking parameter does not affect the behaviour.
Best Regards.