Java.nio Socketchannle.write () simple solution to return 0 __socket

Before using Java IO to implement a file transfer demo, today is going to use Java NiO rewrite.

First of all, using NIO to write a file receiver, the original IO program test, found that there is no problem.

Then, write the file sender, Bytebuffer size set to 1024, send the end of several times to send a file fragment, in the receiver to combine the formation of files, near and write to the file system.

After the program is written:

1, with a 2K file test, found that there is no problem

2, with a 44k file test, found that the receiving end only accept the content of 23k;

Debugging finds that the Socketchannel.write () loop in the sender end returns 0 after sending about 23k of content

Problem analysis: In the socket programming, for write (), the content of the bandwidth limit can not be sent out in an instant, there should be a buffer. In normal block Io, when the buffer is full, the buffer is full, and immediately returns 0.

Solution: The default buffer for Java NiO is 8k. When it is set to 32*1024 with Setsendbuffersize, a slightly larger file can be sent normally. However, it is still difficult to estimate the size of more than 10 trillion files. After the lookup can return 0 in write, the Op_write register into the selector, and then judge the writable, when selector detect writable, continue to send file fragments. Log off op_write after sending.

But I think it's better to use Java normal IO than this method. Blocking IO CPU consumption is much smaller than NIO.

For large file transmission will buffer capacity increases, can only be a drop in the bucket. The reason is that the maximum capacity of this buffer is limited.

The root cause of the buffer full is the problem with the receiver, assuming that the file is sent from the client to the server, and the client is likely to send the contents of the read file in a while loop.

There are many problems with this:

1, bandwidth, data can not be seconds, in the case of very small bandwidth, write () writes data faster than the buffer to send much faster. The buffer can be compared to a bucket, the bottom of the bucket has a leaky hole, and write is a pump, non-stop to the bucket to send water, bucket of water must overflow.

2, the server receives the processing speed of the terminal. A typical server has multiple threads, and there is a lot more to do with incoming data, such as decoding, rearrangement, and so on. The client performs only one task or thread: The data is sent continuously. This is a typical producer consumer problem, and there is no problem with blocking in ordinary blocking IO. In NiO, write () cannot be written in the case of a full buffer due to read-write non-blocking, returning 0, resulting in data loss

Another solution here is to detect bytebuffer.remanning () and resend it when there is data, until it is sent out. Another to ensure that the CPU, cycle Nega sleep. There is a certain relationship between sleep time and buffer size, the buffer set is large, you can choose a larger sleep time, the fundamental purpose is to ensure that the sending buffer has been data, there is no empty situation.