Каналы данных Webrtc: сохранение данных в файл при передаче больших файлов

Я использую каналы данных WebRTC для создания службы передачи файлов.

С небольшими файлами, до 30 Мб или около того, все идет неплохо. Прямо сейчас на принимающей стороне я просто сохраняю данные файла в памяти, когда все данные передаются, я сохраняю файл.

Вроде так:

//On the recieving side
var dataArray = [];
var dcOnMessage= function(event){
    dataArray .push(event.data);
    if(bytesToRecieve == 0)
    {
        var blob = new Blob(dataArray ,{type: incFileDesc.type});
        reader.onload = function (event) {
            saveToDisk(event.target.result,incFileDesc.name);
        }
        reader.readAsDataURL(blob);
    }
}

var saveToDisk = function(fileUrl, fileName) {
        var save = document.createElement('a');
        save.href = fileUrl;
        save.target = '_blank';
        save.download = fileName || fileUrl;
        var event = document.createEvent('Event');
        event.initEvent('click', true, true);

        save.dispatchEvent(event);
        (window.URL || window.webkitURL).revokeObjectURL(save.href);
    }

Итак, я хочу сохранить данные в файле на диске, а затем записать непосредственно в этот файл. Но как мне это сделать?


person PvPlatten    schedule 17.04.2015    source источник


Ответы (3)


Я боюсь, что текущие стандартизированные API-интерфейсы не позволяют это легко (см. Ответ Филиппа). Наиболее близким было бы сохранить каждый как blob/etc в localstorage/indexeddb, а затем использовать конструктор Blob для создания окончательного файла из набора больших двоичных объектов. У него все еще будет временное попадание в память примерно в 2 раза больше размера файла. Или просто удерживайте каждый большой двоичный объект в памяти до создания окончательного двоичного объекта и сохранения на диск (все еще попадание в память, но постепенное, пока оно не удвоится при создании окончательного двоичного объекта). У них, вероятно, начинаются проблемы, когда размеры конечных файлов достигают диапазона доступной оперативной памяти.

Прямая передача одного большого двоичного объекта в Firefox->Firefox сегодня работает без поддержки SCTP ndata (которая пока недоступна) с использованием устаревшего низкоуровневого механизма фрагментации; он позволяет избежать двукратной части попадания в память.

В Chrome есть нестандартный API, который в основном может выполнять часть добавления в файл, последний раз, когда я проверял. Это была постоянная область обсуждения с людьми WebAPI; наверное пора их снова ткнуть.

person jesup    schedule 21.04.2015

Из-за отсутствия способа добавления данных в большой двоичный объект (см. API BlobBuilder, который никогда не был реализован во всех браузерах), то, что вы делаете, в настоящее время является лучшим способом сделать это. Это может измениться, когда Chrome (как уже делает Mozilla) будет поддерживать отправку BLOB-объектов по каналу данных. .

пример передачи файлов работает достаточно хорошо для файлов размером до гигабайта.

person Philipp Hancke    schedule 17.04.2015

Я не думаю, что вы можете сохранять файлы на диске (из соображений безопасности), но вы можете сохранить их в indexedDB как BLOB. IndexedDB теперь широко поддерживается (см. http://caniuse.com/#search=indexeddb) и подходит для местного магазина крупных предметов. См. https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API для получения дополнительных сведений об API. Вот пример сохранения BLOB в IndexedDB: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/

person peveuve    schedule 17.04.2015