ADCGET-ADCSND и размер файла

День добрый.

Помогите пожалуйста разобраться в следующем при получении файл-листа от пользователя.

В режиме Клиент-Клиент, я отправляю

$Supports MiniSlots XmlBZList ADCGet TTHL TTHF |
$ADCGET file files.xml.bz2 0 -1|
на что получаю
$ADCSND file files.xml.bz2 0 3398|

т.е. файл приходит действительно размером 3398, ужатый в bz2

Теперь краткая справка:


Модифицируем обмен командами с клиентом
$Supports MiniSlots XmlBZList ADCGet TTHL TTHF ZLIG |
$ADCGET file files.xml.bz2 0 -1 ZL1|
и получаем
$ADCSND file files.xml.bz2 0 3398 ZL1|

так вот теперь ужатый bz2 дополнительно ужимается zlib'ом. Естественно меняется и заголовок файла и его конечный размер, но какого тогда ADCSND пишет 3398 байт? Вот тут я и перестаю понимать. Ну, допустим, что 3398 - это размер bz2 и клиент ужимает стрим при отправке, т.е. не может в заголовке указать правильный размер.

1. Каким образом я могу узнать размер файла, который ко мне идёт?
2. Зачем в тех же ApexDC, StrongDC стрим ужимается zlib'ом по умолчанию? Зачем ужимать то, что и так уже ужато? Зачем нужени этот ZLIG ?

Не все файлы можно сжать. Например, практически никакие avi файлы не подлежат сжатию.
Вообще что такое сжатие? Это поиск одинаковых последовательностей символов. Если найдены две одинаковые последовательности, то отсылаться будет только первая из этих последовательностей, а на месте второй будет стоять метка на первую.

Библиотека zlib не сжимает то, что уже нельзя сжать.

Про принципы архивирования ориентируюсь.

Не соглашусь с тем, что zlib не сжимает то, что уже нельзя сжать. Пытается сжимать. По крайней мере при получении файл-листа в архиве .bz2, zlib прописывает как минимум 7 байт в начале файла, начиная с 78 9С (это его заголовок), затем видно, что идет заголовок bz2. А также прописывает свои байты в теле кода. Особо не разбирался, но то что вмешивается - это однозначно.

Вообще, смысл упаковки стрима zlib'oм безусловно имеет право на жизнь при передаче файлов. Но я не понимаю смысла упаковки заведомо упакованного файл-листа. А этим, как я уже сказал, страдают и StrongDC, и ApexDC.

И самое главное, мне нужна помощь в том, как узнать, сколько байт из сокета я должен забрать, т.к. размер файла указанного в $ADCSND заведомо меньше того размера, который придет при ужимании стрима библиотекой zlib.

Хелп!

Нет, не верно. Алгоритм сжатия LZ77 библиотеки zlib устроен так, что он не будет сжимать файл, если размер всех "метадат", которые этот алгоритм вставляет в начале каждого сжатого сегмента будет превышать размер сжатия. То есть алгоритм LZ77 не работает в ущерб

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

Да откуда у меня баги? Я всего лишь прошу клиента прислать мне файл-лист. В зависимости от запроса приходит ответ:

либо так: $ADCSND file files.xml.bz2 0 3398| .....файл
либо так: $ADCSND file files.xml.bz2 0 3398 ZL1| .... файл

в первом случае идет чистый красивый bz2 размером 3398
во втором bz2, ужатый zlib-ом, размером <фиг знает каким>

:(