I am currently using a non-blocking SocketChannel (Java 1.6) to act as a client to a Redis server. Redis accepts plain-text commands directly over a socket, terminated by CRLF and responds in-like, a quick example:

> 
> SEND: 'PING\r\n'
> 
> 
> RECV: '+PONG\r\n'
> 
> 
> 

Redis can also return huge replies (depending on what you are asking for) with many sections of \r\n-terminated data all as part of a single response.

I am using a standard *while(socket.read() > 0) {//append bytes}* loop to read bytes from the socket and re-assemble them client side into a reply.

*NOTE: I am not using a Selector, just multiple, client-side SocketChannels connected to the server, waiting to service send/receive commands.*

What I'm confused about is the **contract** of the *SocketChannel.read()* method in non-blocking mode, specifically, how to know when the server is done sending and I have the entire message.

I have a few methods to protect against returning too fast and giving the server a chance to reply, but the one thing I'm stuck on is:

1. Is it ever possible for *read()* to return bytes, then on a subsequent call return no bytes, but on another subsequent call again return some bytes?

Basically, can I trust that the server is done responding to me if I have received at least 1 byte and eventually *read()* returns 0 then I know I'm done, or is it possible the server was just busy and might sputter back some more bytes if I wait and keep trying?

If it *can* keep sending bytes even after a read() has returned 0 bytes (after previous successful reads) then I have no idea how to tell when the server is done talking to me and in-fact am confused how java.io.\* style communications would even know when the server is "done" either.

As you guys know read never returns -1 unless the connection is dead and these are standard long-lived DB connections, so I won't be closing and opening them on each request.

I know a popular response (atleast for these NIO questions) have been to look at Grizzly, MINA or Netty -- if possible I'd really like to learn how this all works in it's raw state before adopting some 3rd party dependencies.

Thank you.

**Bonus Question:**

I originally thought a blocking SocketChannel would be the way to go with this as I don't really want a caller to do anything until I process their command and give them back a reply anyway.

If that ends up being a better way to go, I was a bit confused seeing that SocketChannel.read() blocks as long as there aren't bytes sufficient to fill the given buffer... short of reading everything byte-by-byte I can't figure out how this default behavior is actually meant to be used... I never know the *exact* size of the reply coming back from the server, so my calls to SocketChannel.read() always block until a time out (at which point I finally see that the content was sitting in the buffer).

I'm not real clear on the right way to use the blocking method since it always hangs up on a read.