Re: Про потоковое сжатие.

Только учти что сейчас многие провайдеры секут фишку :)

У нас на тестовом входе все icmp позакрывали :)

А на счет сжатия - результат сомнительным будет скорее всего. Все что можно жмет модем.

Re: Про потоковое сжатие.

gzip

bzip2

Re: Про потоковое сжатие.

Хорошо подойдёт deflate (обыкновенный LZ77) с большим словарём. Он потому и стандарт де-факто при обмене, что прекрасно работает в потоке (можно дешифровать данные _сразу_ после получения, не дожидаясь "границ блока данных" и т п).

Всю информацию и ссылки на свободные реализации есть тут: http://datacompression.info/LZSS.shtml

Там же можно для развития почитать, как, например, работает Барроуз-Уилер (bzip2), и почему он не подходит для сжатия траффика.

У меня был такой проект - цепочка из двух прокси на Java, чтобы пускать сжатый траффик через провайдера. Выбрал такой подход: стандартную реализацию deflate из Java, только вручную управлял словарём, сделав его, так сказать, побольше и подинамичнее. Результат хороший: на html-сайты без картинок и flash при просмотре уходит в 3-4 раза меньше траффика

Re: Про потоковое сжатие.

> Хорошо подойдёт deflate (обыкновенный LZ77) с большим словарём. Он потому и стандарт де-факто при обмене, что прекрасно работает в потоке (можно дешифровать данные _сразу_ после получения, не дожидаясь "границ блока данных" и т п).

да ну, там все равно есть фрэймы/блоки/окна данных, то есть не чисто потоковое сжатие .. чисто потоковое сжатие работает только на пеональном токовом компьютере ;)

Re: Про потоковое сжатие.

ДА КАЖИСЯ оно самое. Спасибо.

Re: Про потоковое сжатие.

в сетях не разбираюсь, но ipsec умеет сжимать.

Re: Про потоковое сжатие.

А че это идею - веб рафик тунелировать в ipsec, а его уже в icmp. Еще лучше если это https трафик. Такую кашу провайдер точно не разберет :)