Java NIO: TransferFrom до конца потока

Есть несколько способов справиться с этим делом. Некоторая справочная информация о внутренней реализации trasnferTo/From и в каких случаях она может быть лучше.

• Прежде всего, вы должны знать, сколько байтов у вас есть для xfer, т.е. используйте FileChannel.size() для определения максимально доступного и суммирования результата. Дело относится к FileChannel.trasnferTo(socketChanel)
• Метод не возвращает -1
• Метод эмулируется в Windows. В Windows нет функции API для перехода из дескриптора файла в сокет, у нее есть одна (две) функция для перехода из файла, обозначенного именем, но это несовместимо с java API.
• В Linux используется стандартный sendfile (или sendfile64), в Solaris он называется sendfilev64.

короче for (long xferBytes=0; startPos + xferBytes<fchannel.size();) doXfer() будет работать для передачи из файла -> сокет. Нет функции ОС, которая переходит из сокета в файл (что интересует OP). Поскольку данные сокета не находятся в кеше ОС, это невозможно сделать так эффективно, это эмулируется. Лучший способ реализовать копирование — использовать стандартный цикл с использованием опрашиваемого прямого байтового буфера, размер которого соответствует размеру буфера чтения сокета. Поскольку я использую только неблокирующий ввод-вывод, который также включает селектор.

При этом: Я хотел бы, чтобы он работал с якобы суперэффективным "? - он неэффективен и эмулируется во всех ОС, поэтому он завершит передачу, когда сокет закрыт. изящно или нет.Функция даже не вызовет унаследованное IOException, при условии, что была ЛЮБАЯ передача (если сокет был доступен для чтения и открыт).

Надеюсь, ответ ясен: единственное интересное использование File.transferFrom происходит, когда источником является файл. Наиболее эффективным (и интересным) случаем является файл->сокет и файл->файл, реализованный через filechanel.map/отменить сопоставление(!!).

Прямо отвечая на ваш вопрос:

while( (count = socketChannel.read(this.readBuffer) )  >= 0) {
   /// do something
}

Но если это то, что вы делаете, вы не используете никаких преимуществ неблокирующего ввода-вывода, потому что вы фактически используете его точно так же, как блокирующий ввод-вывод. Суть неблокирующего ввода-вывода в том, что 1 сетевой поток может одновременно обслуживать несколько клиентов: если нечего читать из одного канала (т.е. count == 0), можно переключиться на другой канал (принадлежащий другому клиентскому соединению).

Таким образом, цикл должен фактически перебирать разные каналы, а не читать из одного канала, пока он не закончится.

Взгляните на это руководство: http://rox-xmlrpc.sourceforge.net/niotut/ Думаю, это поможет вам разобраться в этом вопросе.

Я не уверен, но JavaDoc говорит:

Предпринимается попытка считать байты из исходного канала и записать их в файл этого канала, начиная с заданной позиции. Вызов этого метода может передавать или не передавать все запрошенные байты; будет ли это так, зависит от характера и состояния каналов. Будет передано меньше запрошенного количества байтов, если в исходном канале осталось меньше, чем count байтов, или если исходный канал является неблокирующим и имеет меньше, чем count байтов, непосредственно доступных во входном буфере.

Я думаю, вы можете сказать, что указание копировать бесконечные байты (конечно, не в цикле) сделает эту работу:

out.transferFrom(sChannel, out.position(), Integer.MAX_VALUE);

Итак, я предполагаю, что когда соединение сокета будет закрыто, состояние изменится, что остановит метод transferFrom.

Но, как я уже сказал: я не уверен.

якобы сверхэффективный FileChannel.transferFrom.

Если вам нужны как преимущества доступа DMA, так и неблокирующий ввод-вывод, лучший способ — отобразить файл в память, а затем просто прочитать из сокета в буферы, отображаемые в памяти.

Но это требует, чтобы вы предварительно выделили файл.

Сюда:

URLConnection connection = new URL("target").openConnection();
File file = new File(connection.getURL().getPath().substring(1));
FileChannel download = new FileOutputStream(file).getChannel();

while(download.transferFrom(Channels.newChannel(connection.getInputStream()),
        file.length(), 1024) > 0) {
    //Some calculs to get current speed ;)
}

transferFrom() возвращает число. Просто продолжайте вызывать его, продвигая позицию/смещение, пока он не вернет ноль. Но начните с гораздо большего количества, чем 1024, больше похожего на мегабайт или два, иначе вы не получите большой пользы от этого метода.

EDIT Чтобы ответить на все комментарии ниже, в документации говорится, что «меньше запрошенного количества байт будет передано, если в исходном канале осталось меньше count байтов или если исходный канал не блокируется. и имеет меньше, чем count байтов, непосредственно доступных во входном буфере». Поэтому, если вы находитесь в режиме блокировки, он не вернет ноль, пока в источнике ничего не останется. Таким образом, цикл до тех пор, пока он не вернет ноль, действителен.

ИЗМЕНИТЬ 2

Методы передачи, безусловно, неправильно разработаны. Они должны были быть спроектированы так, чтобы возвращать -1 в конце потока, как и все методы read().

Основываясь на том, что здесь написали другие люди, вот простой вспомогательный метод, который достигает цели:

public static void transferFully(FileChannel fileChannel, ReadableByteChannel sourceChannel, long totalSize) {
    for (long bytesWritten = 0; bytesWritten < totalSize;) {
        bytesWritten += fileChannel.transferFrom(sourceChannel, bytesWritten, totalSize - bytesWritten);
    }
}