Replies To: byte array size 1 or 2048 or whatever

Re: byte array size 1 or 2048 or whatever

You'd set up a "buffer" of X size. The read command tells you how many bytes it actually got. Each read overwrites the buffer.

In practice, the buffer will always be completely full until maybe the last read, when it will have some fraction of the capacity read. The read after that will have zero, because there's nothing left. Then you're done.

Re: byte array size 1 or 2048 or whatever

Posted 02 April 2012 - 06:32 PM

It is fully explained in the API

public int read(byte[]
throws IOException Reads some number of bytes from the input stream and stores them into the buffer array b. The number of bytes actually read is returned as an integer. This method blocks until input data is available, end of file is detected, or an exception is thrown.
If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b.

The first byte read is stored into element b[0], the next one into b[1], and so on. The number of bytes read is, at most, equal to the length of b. Let k be the number of bytes actually read; these bytes will be stored in elements b[0] through b[k-1], leaving elements b[k] through b[b.length-1] unaffected.

Re: byte array size 1 or 2048 or whatever

Posted 02 April 2012 - 06:40 PM

pbl, on 02 April 2012 - 09:32 PM, said:

It is fully explained in the API

Well, not fully -- unless I'm overlooking something.

The API says "The number of bytes read is, at most, equal to the length of b." It doesn't fully explain why, or when, it will be less than b. In this case, where I set up a 5000 byte buffer, why is it reading one chunk of 2617 bytes, followed by a series of 1452 byte reads?

And why, when I ask it to read 1451 bytes, does it read mostly 1450 byte chunks, but occasionally 1449 and occasionally 1451?

Re: byte array size 1 or 2048 or whatever

Posted 02 April 2012 - 06:56 PM

Nothing said that reading from a socket you'll get all the byte at once
If you read from a modem line you might receive 512 bytes frames.
You don;t know from the sender, it can send a packet of a buffer size you ignore, then it may proceed with other requests, and come back later to continue the job. At time time, your client will have read the first buffer.

When you go with your browser on an heavily used site, like your bank site, never seen that the browser can change the layout of the displayed page a few times ? It is because it does not have yet all the information to display the full page. So it starts with what it has, and then reformat the page, as required, when new frames are accepted an available until the whole page is transmitted. Some sites, to let beleive the users that they have an immediate response time, trasnmit a small frame to all clients (so your browser can start to react), then another frame to all clients,... and so on

Re: byte array size 1 or 2048 or whatever

Posted 03 April 2012 - 05:50 AM

InputStream is a top level abstraction.

I was thinking of files, so I'll try to be more clear. Read will try to get data and fill its buffer. If it gets some data on request, it may come back with just that. The reason is that not all streams are created equal.

Re: byte array size 1 or 2048 or whatever

Posted 03 April 2012 - 07:06 AM

So would it be accurate to say that read will be "satisfied" (i.e. stop blocking and extract the data) whenever it finds anything in the stream?

And the read amounts that we're seeing are being limited by the amounts of data that the OS found in the packets it received, and the relative timing of when the OS actually placed that data in the stream vs. when the application gets to access the stream?

Re: byte array size 1 or 2048 or whatever

So would it be accurate to say that read will be "satisfied" (i.e. stop blocking and extract the data) whenever it finds anything in the stream?

And the read amounts that we're seeing are being limited by the amounts of data that the OS found in the packets it received, and the relative timing of when the OS actually placed that data in the stream vs. when the application gets to access the stream?