reading from socket channel

[Kiran Kumar]

Hello,
API doc for reading (read method ) from SocketChannel says:

______________________________________________________________________________

A read operation might not fill the buffer, and in fact it might not read any
bytes at all. Whether or not it does so depends upon the nature and state of the
channel. A socket channel in non-blocking mode, for example, cannot read any more
bytes than are immediately available from the socket's input buffer; similarly, a
file channel cannot read any more bytes than remain in the file. It is guaranteed,
however, that if a channel is in blocking mode and there is at least one byte
remaining in the buffer then this method will block until at least one byte is
read.
______________________________________________________________________________

ByteBuffer buffer = ByteBuffer.allocate(2048);
if( key.isReadable() ){
SocketChannel channel = (SocketChannel) key.channel();
channel.read(buffer);
key.cancel();
}
Say client sends 20 bytes of data. I hope the doc does't mean that I *might*
get 3 bytes now and 17 bytes *later*. Probably there is somethign wrong
with my understanding. Can anyone please clarify. Surely, nothing can be
with nio if there is such uncertainity.

Kiran

 

[Steve Horsley]

Hello,
API doc for reading (read method ) from SocketChannel says:

______________________________________________________________________________

A read operation might not fill the buffer, and in fact it might not read any
bytes at all. Whether or not it does so depends upon the nature and state of the
channel. A socket channel in non-blocking mode, for example, cannot read any more
bytes than are immediately available from the socket's input buffer; similarly, a
file channel cannot read any more bytes than remain in the file. It is guaranteed,
however, that if a channel is in blocking mode and there is at least one byte
remaining in the buffer then this method will block until at least one byte is
read.
______________________________________________________________________________

ByteBuffer buffer = ByteBuffer.allocate(2048);
if( key.isReadable() ){
SocketChannel channel = (SocketChannel) key.channel();
channel.read(buffer);
key.cancel();
}
Say client sends 20 bytes of data. I hope the doc does't mean that I *might*
get 3 bytes now and 17 bytes *later*. Probably there is somethign wrong
with my understanding. Can anyone please clarify. Surely, nothing can be
with nio if there is such uncertainity.

Kiran

It says exactly that. There is nothing wrong with your understanding
except knowing _why_ it's like this.

Imagine you are reading over a network connection - a TCP connection
or maybe an network-mounted file. Data arrives in chunks - packets. The machine
cannot know how much more will arrive or when, so a read() call will return
what is essentially an unpredictable amount - however much has arrived so far.

The size of packets arriving may not correspond with the size of the sender's
write() requests either, for two reasons:
* Fragmentation - chunks may get broken up into separate packets if the
network media only supports smaller packets, e.g. Ethernet only carries
packets up to 1540 bytes.
* Concatenation - if two chunks get stored in a buffer somewhere they may well
then get removed from the buffer as one chunk. This can happen in a transmit
buffer is the sender has to wait for network availability, or more likely,
if two packets arrive at the receiving PC before the application gats round to
calling read() on the socket.

TCP guarantees to deliver a byte STREAM in order, with no loss or duplication.
It makes NO guarantee as to grouping - it doesn't transport byte arrays,
just bytes. Any higher structure must be encoded into that byte stream as you
would if writing several records to one file.

Steve