Теория, как сократить объём трафика по сети, Что-то вроде дельта кодирования.. Опции

[Алексей1153]

Iron Bug, и в GIF похоже делается.

512es, алгоритм то, может, и хороший, а вот как насчёт скорости работы ? При передаче экрана скорость была критична - задержек и так куча: сжатие, передача, распаковка.

[zloiia]

Быть может немного не в тему, но может не стоит изобретать велосипед и просто попробовать данные упаковать? Например тем-же самым QByteArray::qCompress[\url] ? А если уж в упор хочется diff иметь, то может стоит посмотреть в сторону [url=http://code.google.com/p/google-diff-match-patch/]google-diff-match-patch

Быть может немного не в тему, но может не стоит изобретать велосипед и просто попробовать данные упаковать? Например тем-же самым QByteArray::qCompress ? А если уж в упор хочется diff иметь, то может стоит посмотреть в сторону google-diff-match-patch
PS: господа модераторы, грохните мое предыдущее сообщение, если не трудно. накосячил с разметкой

[Алексей1153]

zloiia, всё зависит от критичности времени обработки. Если ему скорость неважна, но важен траф - пусть изголяется )) Архиватор будет пошустрее, но траф вырастет. А в случае с постоянным объёмом (видеокадры) - лучшее решение - именно разность

[512es]

Алексей1153, скорость да, уступает простому вычитанию, зато в трафике выигрыш реальный.

Кстати, ещё по поводу передачи экрана. Представьте ситуацию когда окно двигают по однородному фону рабочего стола. Если использовать простое вычитание, то трафик будет достаточно большой, так как надо перерисовывать всю затронутую область экрана. А если использовать умные алгоритмы то окно не придётся постояно передавать. Этот блок данных как был неизменным, так и останется. Просто он будет подвинут вслед за окном.

Скорость создания патча bsdiff-ом на моих опытах составляет около 1.5 секунды, а скорость применения патча всего 0.02 секунды. В реалтайм программах ксожалению врядли получится использовать.
У bsdiff-а больше область использования в заранее подготавливаемых данных. Например кодирование фильмов, бекапы, обновлялки.

zloiia,
google-diff-match-patch это для текстовых данных. А тут речь идёт о бинарных.
А про qCompress сказано ещё в первом посте. Так и используется сейчас. Просто разница в том что, например, передавать 580кб (архив) данных или 40кб (дельта-патч)? Если цифры кажутся не внушительными, помножте оба значения на 10, на 100, на 1000...

Сообщение отредактировал 512es - 20.1.2012, 11:16

[Алексей1153]

когда окно двигают по однородному фону рабочего стола. Если использовать простое вычитание, то трафик будет достаточно большой, так как надо перерисовывать всю затронутую область экрана.

тут ещё следует учесть, что для снижения трафика отключают обои, Аэро и прочую хрень. Даже если окно сдвинуто, всё равно там много одинаковых цветов друг на друга наложилось (белый фон, серый фон) , плюс искусственное ограничение глубины цвета (4 бита/пиксел - вполне нормально для техподдержки). Так что разность всё равно обычно хорошо сжимается, а редкие всплески трафа на одиночном кадре утонут в общей экономии. Ну и, опять же, рекомендуется безлимит для таких вещей

Скорость создания патча bsdiff-ом на моих опытах составляет около 1.5 секунды,

ага, потом прибавим 1 секунду передачи по тырнету... Слайдшоу обеспечено. Ещё учти запыхавшийся процессор

[512es]

Алексей1153, кстати, а что вас заставило изобретать велосипед? Ведь есть же VLC, где используются эффективные и быстрые алгоритмы сжатия. Работает даже при совсем плохом инете и имеет кучу настроек.

[Алексей1153]

512es, задача была - написать систему удалённого администрирования (простенькую, но достаточную) , не использующую левого кода. Там даже парочка недоделок осталась, когда-нибудь на досуге доведу до ума )) А заказчик уже был доволен. Жалею только, что маловато запросил по цене - но потом переобуваться было уже несолидно. Да и перерыв в три недели был в середине проекта - я переезжал в новую квартиру в тот момент - зак очень нервничал
http://www.free-lance.ru/users/alex1153/vi...p?prjid=2826191

[Iron Bug]

При передаче экрана скорость была критична - задержек и так куча: сжатие, передача, распаковка.

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

Алексей1153, кстати, а что вас заставило изобретать велосипед? Ведь есть же VLC, где используются эффективные и быстрые алгоритмы сжатия. Работает даже при совсем плохом инете и имеет кучу настроек.

VLC не опенсорц, и для многих систем он платный. а старый не будет работать под новой 64-битной семёркой, например (проверено на практике).

[Алексей1153]

никакое сжатие-распаковка не может быть медленнее, чем передача по сети

не у всех 8-яйцевые монстры с 4 гигами на борту Не забывай.

[Iron Bug]

не у всех 8-яйцевые монстры с 4 гигами на борту Не забывай.

любой комп при общении с памятью шустрее периферии. даже x86-е. это аппаратная фича: не может шина пропускать поток с девайсов быстрее, чем обращения от проца к памяти. а уж всякие там TCP-стеки и подавно тормозные, а есть ещё сеть, которая даёт сбои и прочее, и прочее.