FTP сервер на STM-ке, подход к верификации данных Опции

[Danis]

Привет, коллеги!
Недавно поднял на STM32Fxx FTP сервер и удаленно через Internet пишу файлы во внешнюю flash память. Все неплохо работает, есть вопрос с подходом к верификации данных в принятых файлах. Я использую ftp passive mode, и по сути, аппаратно верифицируются только пакеты пришедшие с Ethernet, можно конечно и проверить пакет после записи на SD. Но этого не достаточно для полного убеждения о целостности файла. Я тут вижу два пути, сначала записать удаленно файл, и скачать обратно, сравнить их Hash (долго, если файл большой). Второй, научить STM-ку считать Hаsh уже записанных файлов по команде (возможно не стандартной) FTP и создавать *.txt файл с Hаsh суммами файлов в текущей директории. После чего можно скачать этот файл и проверить. Но наверняка, есть более красивый и правильный подход, которого я не знаю, так что буду рад подсказке, спасибо!

[WitFed]

Про TCP я читал очень давно, как там дополнительно контролируется содержимое внутри уже проверенного внешним CRC32 пакета, но CRC32 вполне себе очень доверятельная вещь !
По инету всё им проверяется на вшивость, мужики очень умные придумывали. И просто, и надёжно.
Там на каждый единичный бит в исходном файле к 4-байтному результату XOR-ится уникальное 32-битное число, и если бит/байт или их группа рядом где-то испортится, как обычно бывает в импульсных глюках, то проксорится уже другая цепочка, и вероятность получить тот же код невероятно мала. Для получения той же CRC32 для других данных нужен очень мощный перебор.
Происходит вычурная однозначная трансляция из всего множества файлов разных длин в множество 32-битных чисел, которая, естественно, может несколько файлов отобразить в одно и то же число, но на практике это не бывает, особенно если несколько байт изменено, а остальные прежние.
Вообще, я считаю, что нужно сначала ошибку увидеть, а потом её начинать бояться, солому стелить как-то... Флэшь тоже может сбоить -- вот там нужны CRC32 в каталоге для каждого файла или даже у каждого сектора, как раньше было у HDD.
А у провайдера кэш глючил на прокси (ОЗУ/винт SSD), скорей всего -- они файл получили, куда-то сохранили, потом считали побитый, на пакеты порезали, новой CRC32 закрыли -- и передали, типа "усё хоккей".

[jcxz]

Про TCP я читал очень давно, как там дополнительно контролируется содержимое внутри уже проверенного внешним CRC32 пакета, но CRC32 вполне себе очень доверятельная вещь !

Ещё раз внимательно читаем по слогам: в TCP-кадрах нет CRC32-контроля.
Вот расчёт контрольной суммы для TCP-кадра из рабочего TCP-стека:

CODE

static s32 CalcCsum(void const *start, int cnt, s32 sum)
{
u16 const *p = (u16 const *)start;
while ((cnt -= 2) >= 0) sum += *p++; //sum words
if (!(cnt + 1)) sum += *(u8 *)p; //add left-over byte, if any
while ((u32)(sum = (sum & 0xFFFF) + ((u32)sum >> 16)) >> 16); //fold 32-bit sum to 16 bits
return ~sum;
}

Покажите мне - где здесь CRC32????

[kolobok0]

...где здесь CRC32????

Вам шашечки или ехать?
От противного =>
Вы утверждаете, что контрольая сумма даёт сбои при конкретной реализации и посему TCP не надёжен в плане сетевой передачи?

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

[jcxz]

Вы утверждаете, что контрольая сумма даёт сбои при конкретной реализации и посему TCP не надёжен в плане сетевой передачи?

Пропускают ошибки любые методы контроля. Вопрос в вероятности. А по этому критерию CRC32 несравнимо лучше обычной суммы.
И если поддаться паранойе, то можно не ограничиваться 32 разрядами. Есть полиномы и на большие разрядности.

Хорошо, в TCP простая сумма. Но этот TCP идет поверх Ethernet, в котором как раз таки CRC-32.

А где ТС пишет, что клиент и сервер находятся в одной Ethernet-сети?
Он вроде про Интернет пишет. А значит - на пути следования пакета могут быть различные физические+канальные среды передачи.
Плюс - переход пакета из одного сегмента сети в другой, через кучу маршрутизаторов.
Не здесь-ли и возникают сбои, приводящие к ошибкам в принятых по FTP файлах?

А ещё - как я понимаю для Ethernet обязательно только формирование кадров с CRC, но не обязателен контроль этой CRC на приёмной стороне.

Такая контрольная сумма весьма не дурна, но не гениальна. Она не замечает перестановку слов, и двойную ошибку одного бита. Учитывая сетевой протокол, избыточное кодирование и прочее она годиться для ТСР (вот теперь сижу вспоминаю а есть ли там избыточное кодирование), и дает единицы ошибок в год, но CRC32 в разы надежнее...

Я бы сказал - не в разы, а на порядки. Учитывая кол-во разрядов в контрольной сумме TCP и в CRC32. Уж не говоря о том что даже CRC16 будет надёжнее обычной суммы.
Кодирование - это функция вроде канального или физического уровня протокола (в частности - Ethernet-уровня или какой там канальный/физический уровень в данном сегменте). А TCP - это более высокий уровень OSI.