Как объединенить (конкатенация) две CRC суммы ? Опции

[Pechkin]

Good Day.
I transfer a packet by chunks and use boost library for computing crc (16 bits).
I obtain other checksums for whole byte's array and concatenation by chunks.
For example:
Добрый день.
Я передаю пакет по частям. и использую для этого библиотеку boost (16 bits).
Я получаю различные контрольные суммы для целого массива байт и для объединения по частям.
Для примера:
шаг1

boost::crc_16_type  crcobject;
...
memcpy(ba_tosocket->data()+offset,(char *)&bin_tosocket[0],headersize);
                crcobject.reset(0);
                crcobject.process_bytes(ba_tosocket->data(),headersize);
                bin_tosocket[3] = crcobject.checksum();

шаг2

memcpy(ba_tosocket->data()+offset,batmp.data(),dataframesize);
                crcobject.reset(bin_tosocket[3]);
                crcobject.process_bytes(ba_tosocket->data(),dataframesize);
                bin_tosocket[3] = crcobject.checksum();

Является ли такой подход правильным ?

[lanz]

typedef crc_optimal<16, 0x8005, 0, 0, true, true>         crc_16_type;

Последнее true говорит о том что данная CRC использует инверсию остатка:

Reflected (remainder) output
Some CRCs return the reflection of the interim remainder (taking place before the final XOR value stage).

Так что я бы не стал.
Если очень нужно, то можно просто проверить.

Вообще же правильно делать так:

boost::crc_16_type  crcobject;
...
crcobject.reset(0);
memcpy(ba_tosocket->data()+offset,(char *)&bin_tosocket[0],headersize);
crcobject.process_bytes(ba_tosocket->data(),headersize);
bin_tosocket[3] = crcobject.checksum();

memcpy(ba_tosocket->data()+offset,batmp.data(),dataframesize);
// нет reset
crcobject.process_bytes(ba_tosocket->data(),dataframesize);
bin_tosocket[3] = crcobject.checksum();

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

[Pechkin]

typedef crc_optimal<16, 0x8005, 0, 0, true, true>         crc_16_type;

Последнее true говорит о том что данная CRC использует инверсию остатка:

Reflected (remainder) output
Some CRCs return the reflection of the interim remainder (taking place before the final XOR value stage).

Так что я бы не стал.
Если очень нужно, то можно просто проверить.

Вообще же правильно делать так:

boost::crc_16_type  crcobject;
...
crcobject.reset(0);
memcpy(ba_tosocket->data()+offset,(char *)&bin_tosocket[0],headersize);
crcobject.process_bytes(ba_tosocket->data(),headersize);
bin_tosocket[3] = crcobject.checksum();

memcpy(ba_tosocket->data()+offset,batmp.data(),dataframesize);
// нет reset
crcobject.process_bytes(ba_tosocket->data(),dataframesize);
bin_tosocket[3] = crcobject.checksum();

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

Спасибо, проблема решена. Контрольная сумма и считается одна для каждого пакета, но пакет больше того куска который может быть передан за раз. Точнее можно конечно сделать буфер под гигабайт (qtcpsocket выдержит, qudpsocket нет) но это приводит сразу к неприятным последствиям
1)пику в нагрузке что чревато например блокировкой пользовательского интерфейса на несколько секунд, если передача пакетов и пользовательский интерфейс в одном потоке.
2)пику в аллокации буфера памяти или в необходимости иметь буфер большого размера.
Поэтому передача пакета разбита на части между которыми происходит цыклы обработки событий.

Для каждого куска считать контрольную сумму нет смысла потомучто пакет это логическая сущность которая в том числе и ядром операционной системы может разбита произвольно на несколько пакетов транспортного уровня модели OSI и например отправив два куска можно принять три.