Почему записи SocketChannel всегда завершаются на полную сумму даже на неблокирующих сокетах?

Мне удалось воспроизвести ситуацию, которая может быть похожа на вашу. Я думаю, что по иронии судьбы ваш получатель потребляет данные быстрее, чем вы их пишете.

import java.io.InputStream;
import java.net.ServerSocket;
import java.net.Socket;

public class MyServer {
  public static void main(String[] args) throws Exception {
    final ServerSocket ss = new ServerSocket(12345);
    final Socket cs = ss.accept();
    System.out.println("Accepted connection");

    final InputStream in = cs.getInputStream();
    final byte[] tmp = new byte[64 * 1024];
    while (in.read(tmp) != -1);

    Thread.sleep(100000);
  }
}



import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SocketChannel;

public class MyNioClient {
  public static void main(String[] args) throws Exception {
    final SocketChannel s = SocketChannel.open();
    s.configureBlocking(false);
    s.connect(new InetSocketAddress("localhost", 12345));
    s.finishConnect();

    final ByteBuffer buf = ByteBuffer.allocate(128 * 1024);
    for (int i = 0; i < 10; i++) {
      System.out.println("to write: " + buf.remaining() + ", written: " + s.write(buf));
      buf.position(0);
    }
    Thread.sleep(100000);
  }
}

Если вы запустите приведенный выше сервер, а затем сделаете попытку указанного выше клиента записать 10 фрагментов данных по 128 КБ, вы увидите, что каждая операция записи записывает весь буфер без блокировки. Однако, если вы измените вышеуказанный сервер так, чтобы он ничего не читал из соединения, вы увидите, что только первая операция записи на клиенте будет записывать 128 КБ, тогда как все последующие записи будут возвращать 0.

Вывод, когда сервер читает из соединения:

to write: 131072, written:  131072
to write: 131072, written:  131072
to write: 131072, written:  131072
...

Вывод, когда сервер не читает соединение:

to write: 131072, written:  131072
to write: 131072, written:  0
to write: 131072, written:  0
...  

Я работал с UDP в Java и видел действительно «интересное» и совершенно недокументированное поведение в материалах Java NIO в целом. Лучший способ определить, что происходит, — посмотреть исходный код, поставляемый с Java.

Я бы также поставил на то, что вы можете найти лучшую реализацию того, что ищете, в любой другой реализации JVM, такой как IBM, но я не могу гарантировать это, не посмотрев на них сам.

Я сделаю большой скачок веры и предположу, что базовый сетевой провайдер для Java такой же, как и для C... ОС выделяет больше, чем просто SO_SNDBUF для каждого сокета. Бьюсь об заклад, если вы поместите свой код отправки в цикл for(1,100000), вы в конечном итоге получите успешную запись со значением меньше запрошенного.

Вам действительно стоит обратить внимание на структуру NIO, такую ​​как MINA или Гризли. Я с большим успехом использовал MINA на корпоративном чат-сервере. Он также используется в чат-сервере Openfire. Grizzly используется в реализации Sun JavaEE.

Куда вы отправляете данные? Имейте в виду, что сеть действует как буфер, размер которого как минимум равен вашему SO_SNDBUF плюс SO_RCVBUF получателя. Добавьте это к чтению приемником, как упоминал Александр, и вы можете получить много данных.

Я нигде не могу найти это задокументировано, но IIRC[1], send() гарантированно либо а) полностью отправит предоставленный буфер, либо б) потерпит неудачу. Он никогда не завершит отправку частично.

[1] Я написал несколько реализаций Winsock (для Win 3.0, Win 95, Win NT и т. д.), так что это может быть специфичным для Winsock (а не общим сокетом) поведением.