загрузка большого количества файлов

Question

Я исследую решения для потенциального клиента. Они запрашивают возможность загружать большое количество MP3 (более 1000) из своего онлайн-каталога.

Я исследовал / протестировал создание zip-файла, содержащего все MP3-файлы, используя ZipArchive, но столкнулся с очевидными проблемами утечки памяти, которые исключили это решение.

Я сейчас пытаюсь мыслить нестандартно.

Одной из идей было создать для них очередь FTP или ссылку для скачивания типа Torrent. Есть ли что-нибудь, что могло бы спровоцировать нечто подобное?

Любая помощь или предложенное направление будет принята с благодарностью! Спасибо !!

Редактировать: Вот общий процесс / цель, которую мы пытаемся достичь.

Клиент создает музыку для размещения TV / Flim. Они поддерживают онлайн-каталог и локальную копию, которую они отправляют потенциальным покупателям. Онлайн-каталог и автономный каталог должны отражать друг друга. Проблема в том, что у них есть несколько офисов, которым придется обновлять свою локальную копию новыми файлами, добавленными в онлайн-каталог из разных мест

Пример: East Coast Пользователь обновляет каталог с 100 новыми файлами. Пользователю West Coast необходимо обновить автономный каталог новыми файлами, извлеченными из онлайн-каталога.

Мы надеялись создать пользовательские zip-файлы для каждого пользователя, необходимые для обновления своего каталога, на основе истории загрузок пользователя, которую мы будем хранить в MySQL. Мы тестировали ZipArchive, но мы не могли создать Zips более 175 MEG (дай или возьми). Мы находимся в процессе тестирования ZipStreaming, но у нас есть некоторые проблемы.

Надеюсь, это прояснит общую цель и проблемы, с которыми мы сталкиваемся.

Answer 1

GNU wget?Это может загрузить рекурсивный.Просто дайте wget список всех файлов на сервере, например, eG http://www.example.org/filelist.html, который содержит ссылки вроде file1.mp3, file2.mp3 и т. Д. (Apache обычно генерирует такой индексный файл автоматически, когда каталог без index.html / phpон вызывается.

http://linux.die.net/man/1/wget

Answer 2

Честно говоря, я не могу определить актуальную проблему / вопрос из вашего поста. Если вы ищете минимизацию сетевой нагрузки, то вам следует помнить, что файлы MP3 не сжимаются должным образом, потому что они уже сжаты (не так хорошо, как хорошо, но хорошо). Если вы ищете транспорт, то подойдет любой протокол передачи файлов (FTP, SFTP, HTTP, WebDAV).

Если вам нужна гибкость и функции, я бы порекомендовал SFTP: это протокол для удаленного доступа к файловой системе, поэтому помимо операции «получить файл», в нем есть много полезных операций, включая машиночитаемый список каталогов (не всегда доступен в FTP и недоступно в стандартном HTTP), встроенное сжатие ZLib, встроенная возможность возобновления передачи файлов и дополнительные бонусы. HTTP также имеет сжатие ZLib, но это не всегда доступно.

Обновление: ваш подход не заботится о том, что действительно доступно на клиенте, и вы собираетесь готовить ZIP-файлы на основе ваших (возможно, неправильных) знаний о клиенте, которые уже есть.

Если клиент и сервер являются приложениями, которые вы разрабатываете, то вам следует использовать протокол RSync или что-то подобное для обновления данных в Интернете (без использования ZIP-файлов) и загрузки файлов, отсутствующих на клиенте. Если прямая связь между клиентом и сервером невозможна, вы можете заставить клиента отправлять свое состояние на сервер, после чего сервер подготовит отдельный пакет. Что касается функциональности ZIP - это необходимо только при использовании пакетного обновления (нет связи в реальном времени между клиентом и сервером). Я не знаю, какую технологию вы используете, но если ваша проблема only связана с ZIP-компонентом, вы можете использовать что-то другое для упаковки данных - либо другой ZIP-компонент (для .NET и VCL у нас есть Компонент ZIP ) или другое упаковочное решение (например, наш продукт SolFS не имеет ограничений по размеру). К сожалению, я не знаю о RSync-подобной реализации, доступной как компонент.