Flush() in Asynchronous NIO Channels

Question

I wrote an asynchronous client-server socket implementation based fully on NIO Channels. My implementation does include old Socket or ServerSocket classes, I used only SocketChannel and ServerSocketChannel classes, with ByteBuffer's to send/receive data on non-blocking channel mode.
Everything looks very comfortable except one thing, looks like old FLUSH() method from OutputStream is still required in NIO. My small write requests (3 bytes length) does not reach the destination. I call write() several times but the read() doesn't get any data. So it looks like I need a flush for Channel, but Channel class don't have any flush() method.
I tried two solutions to solve this situation and FAILED:
1-) In Channels class there are newInputStream() and newOutputStream() methods to get InputStream and OutputStream's of ByteChannels. I used OutputStream's flush() method, but as you guess non-blocking mode does not let you to use write/read methods since they are in blocking mode, but my channels are in non-blocking mode. So I failed here.
2) I watched the actual data transmitted from TCP stack using Ethereal, what I see is my packets are send to the destination address SUCCESSFULLY. The problem looks like the receiver side does not take them immediately. I decreased the size of ByteBuffer used in read() at the receiver but nothing changed.
The point is my packets are still not readable from the destination address.

Answer 1

Well, NIO implementation looks different from Stream
implementation for sockets. I solved my problem by
decreasing the buffer size at the receiver side.
Sometimes read() of socket channel returns completely
filled and sometimes with half filled data. I can not
distinguish which one will come but at this point it
is enoughfor me...Yes, but my intent was simply to determine whether the data is receivable at all. However, you've now determined that it is.
In your place I would not be comfortable with the situation that now pertains. The mere fact that reducing the buffer size seems to make it work in your testing environment is hardly a demonstration that it works 100% of the time, nor that it will work properly in production. You need to be able to explain why the change works, and why the code fails with the larger buffer size.
Sylvia