crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

 
Ответить в данную темуНачать новую тему
> Как объединенить (конкатенация) две CRC суммы ?
Pechkin
  опции профиля:
сообщение 3.7.2014, 16:51
Сообщение #1


Новичок


Группа: Новичок
Сообщений: 9
Регистрация: 30.1.2014
Пользователь №: 4044

Спасибо сказали: 0 раз(а)




Репутация:   0  


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
  опции профиля:
сообщение 3.7.2014, 20:10
Сообщение #2


Старейший участник
****

Группа: Участник
Сообщений: 690
Регистрация: 28.12.2012
Пользователь №: 3660

Спасибо сказали: 113 раз(а)




Репутация:   8  


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
  опции профиля:
сообщение 3.7.2014, 20:58
Сообщение #3


Новичок


Группа: Новичок
Сообщений: 9
Регистрация: 30.1.2014
Пользователь №: 4044

Спасибо сказали: 0 раз(а)




Репутация:   0  


Цитата(lanz @ 3.7.2014, 21:10) *
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 и например отправив два куска можно принять три.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 14.10.2019, 23:18