10

Предположим, мне нужно отправить некоторые данные с одного компьютера на другой через довольно быструю сеть ... например, стандартное соединение 100 Мбит (~ 10 МБ / с). Мои жесткие диски являются стандартными жесткими дисками, поэтому их скорость составляет от 30 МБ / с до 100 МБ / с. Поэтому я думаю, что сжатие данных на лету может помочь.

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

Это сложно с компрессорами, такими как GZIP и BZIP2, потому что вы обычно устанавливаете силу сжатия один раз для всей передачи, и мои потоки данных иногда легко, иногда трудно сжать - это делает процесс неоптимальным, потому что иногда я не использую полный процессор, и иногда пропускная способность используется недостаточно.

Существует ли программа сжатия, которая бы адаптировалась к текущему процессору / полосе пропускания и попала в точку, чтобы передача была оптимальной? Идеально для Linux, но мне все еще интересно все решения. Я бы хотел увидеть что-то совместимое с декомпрессорами GZIP / BZIP2, но это не обязательно.

Поэтому я хотел бы оптимизировать общее время передачи, а не просто количество байтов для отправки.

Также мне не нужна распаковка в реальном времени ... сжатия в реальном времени достаточно. Хост назначения может обрабатывать данные позже в свободное время. Я знаю, что это не сильно изменится (сжатие обычно намного более интенсивно использует процессор, чем декомпрессия), но если есть решение, которое может использовать этот факт, тем лучше.

Каждый раз, когда я передаю разные данные, я действительно хочу сделать эти одноразовые переводы максимально быстрыми. Поэтому я не получу выгоду от получения нескольких передач быстрее из-за более сильного сжатия.

Спасибо,

2 ответа2

3

Это актуальный предмет исследований - в первую очередь в области сенсорных сетей, где цель состоит в том, чтобы минимизировать потребление энергии, а не максимизировать пропускную способность. Однако принцип адаптивного сжатия тот же.

Вот недавняя статья профессора из USC.

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

2

Хм, этот вопрос старше одного года, так что это может остаться незамеченным:

В любом случае, Google недавно опубликовал Snappy, который может быть именно тем, что вы ищете, а именно:

[...] Он не нацелен на максимальное сжатие или совместимость с любой другой библиотекой сжатия; вместо этого он стремится к очень высоким скоростям и разумному сжатию. Например, по сравнению с самым быстрым режимом zlib, Snappy на порядок быстрее для большинства входных данных, но в результате сжатые файлы имеют размер от 20% до 100% больше [...]

Он реализован на C++ с привязками, доступными для C и ряда других языков.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .