Здравствуйте, уважаемые коллеги!
Могу ли использовать для контроля целостности принятых пакетов только CRC32 фрейма Ethernet? Я имею ввиду, не контролировать напосредственно контрольные суммы IP, UDP?
Спасибо!

а почему нет ? в данном случае вы рискуете получить битый пакет только в случае когда ошибка возникла во время упаковки TCP/UDP пакета в Ethernet фрейм , что довольно маловероятно потому можно пренебречь контрольной суммой упакованного пакета

А разве при инкапсуляции пакета, эта КС не пересчитывается?

Да, и, похоже, такой способ пройдет, когда данные передаются как минимум по витой пары (не знаю про оптику, про радиоканал). Если же данные передаются через последовательный порт, то там уже необходимо контролировать КС самих протоколов. Я прав?)

Нет, не пересчитывается. Вероятность получить битый IP-пакет с нормальной FCS все же существует, поэтому игнорировать контрольную сумму можно только в крайнем случае.

Гм, тогда я чего-то не понимаю Я думал, что КС аппаратно пересчитывается для каждого передаваемого фрейба, байт за байтом. Не знаю, кто это делает PHY или MAC, но не суть важно...

в данном случае, необходимость контроля не зависит от канала передачи, ошибка протокола может появится исключительно до того как данные будут переданы по каналу (т.е. вы контролируете целостность протокола канального уровня вроде Ethernet а не tcp/udp). Если говорить точнее эта ошибка может появиться в буффере NIC до того как он запакует пакет. Вообще говоря ошибка быть может , но вероятность появления ошибке по вине памяти например , на маленьких буфферах (~1mb) составляет 3 ошибки в год при работе в 24/7/365 (недавно гугл делал исследования) - потому смотрите сами , насколько критично вам такое количество ошибок





Уважаемый aaarrr имел ввиду что контрольная сумма протокола более высокого уровня (tcp,udp, etc ... ) при подсчете контрольной суммы протокола канального уровня (Ethernet) не пересчитывается, но считается по новому для фрейма - выходит двойная защита данных

Почему я и говорю что можно пренебречь - потому как при ошибках FCS вы откидываете этот пакет потому как он повредился в каналах данных
если FCS верная то вероятность получить контрольную сумму вышестоящего протокола довольно низкая (ну разве что у вас совсем уж неадекватное передающее железо)

Чтож, будем считать "вложенные КС", благо это не сложно)
Всем большое спасибо!

с вои 5 копеек:

ещё не сбрасывайте со счетов дефрагментацию на IP уровне на промежуточных хопах. Т.е. изернет вам придёт нормальный, а вот пакет может оказаться битым (например многие свитчи "едут" при повышении нагрузки или не стандартных ситуациях). тут слово "едут" подразумевает не столь явно багу, а то что алгоритм начинает работать не совсем так как ожидалось от него. например слать не в той последовательности фрагменты и т.п. вещи...

(круглый)

Честно говоря, я даже не рассматриваю фрагментированные пакеты.
Мне нужен только "самый простой" UDP.
Поэтому решил урезанный стек написать сам, ну от части в академических целях)

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

эээээээээ собственно это выше чем IP - посему можем(по протоколу) его фрагментировать, если не лезет или заняты...
т.е. другими словами - на приёме UDP пакета Вы должны отрабатывать дефрагментацию. очень часто люди говорят - я не посылаю более чем.....1500... Это то да... Но кто сказал что оно всегда так будет и от нагрузки не зависит?


(круглый)

Так ведь можно заставить систему посылать пакеты с флагом IP_DONTFRAGMENT.

BOOL dontfragment = TRUE ;
setsockopt (sckt, IPPROTO_IP, IP_DONTFRAGMENT, (char*)&dontfragment, sizeof(dontfragment)) ;

Вот и отличненько, поскольку этим стеком будет пользоваться только мое личное ПО, а частота использования будет очень мала (обновление прошивки), то это мне подходит)
Спасибо!

угумс. можно. но при загрузах на промежуточных хопах этот пакет может быть смело удалён (разбить нельзя, пропихнуть нельзя).

т.е. тут надо для себя решить чего важнее и как часто...

удачи вам
(круглый)

Гм, поигрался с сетью немного. Решил, что по возможности, наверно, следует применять готовые, отлаженныи и опробированные решения.
Какие качественных открытые стеки кроме uIP и с tnkernel.com может порекомендовать уважаемое сообщество?
На данным момент нужен только UDP, ну и ICMP (приятно видеть пинг от железки))) )
Может быть есть стеки, где можно выбирать, какие компоненты использовать? По типу коммерческого стека из RL-ARM (Keil)?

тогда ышо +ARP


да и DHCP не помешает.
и то и то реализация копеешные.

(круглый)
ЗЫ
буду упрям (ржу) дефрагментацию стоит поддержать ))

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