Решил создать новый протокол на основе udp.
Преимущества:
* можно выкинуть select, и любые другие проверки. получение данных сразу по прибытию их.
* управление разрывами, UDP уже порван, и разрывы ему не страшны.
* больший контроль соединения, управление разрывами, появляется возможность посылки разных данных, как потока, так и сообщений. так же есть идея приделать возможность посылки пакетов, не требующих подтверждения доставки.
+ очень заманчивые перспективы, появляется много идей, которые просто невозможны на tcp, управляемом системой.
Из проблем организовываются:
* потребуется взять на себя часть функций системы и рулить всем этим делом.
Возникающие вопросы:
* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно?
* (Было что-то еще, надеюсь вспомню по ходу обсуждения, если таковое состоится. )
Также хотелось бы услышать ваше мнение обо всей этой затее.
Было бы неплохо обсудить саму техническую сторону. вопросов с организацией много, и мозги соображают достаточно медленно.
Так же уже видны проблемы в безопасности(в основном при подделке пакетов), что радости не добавляет.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Здравствуйте, LuciferSaratov, Вы писали:
LS>>Эх, твою бы энергию да в мирных целях. MSV>А вы еще не заметили, что цели мирные?
Какие уж там мирные. Скорее, бессмысленные и беспощадные.
Здравствуйте, MikelSV, Вы писали:
MSV>Решил создать новый протокол на основе udp.
MSV>Также хотелось бы услышать ваше мнение обо всей этой затее.
Для начала неплохо было бы определиться с предназначением протокола,
потом ознакомиться с уже существующими.
И только потом, по всей видимости, станет ясно, что все возможные велосипеды
в этой области уже придуманы и разработаны. Но сам процесс познания этой области
весьма полезен.
Здравствуйте, fk0, Вы писали:
T>>CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает.
fk0> Жизненный опыт. CRC даёт хреновейшую защиту от "сбоев оборудования" при обрыве, когда с середины пакета и до конца все байты FFFF или 0000 не важно.
Прошу примера. Мне сложно себе представить, чтобы правильно вычисленная и уложенная CRC не замечатала такие ситуации.
fk0> А контрольная сумма замечательно работает. Кто-то всерьёз полагает, что бред повсеместно приведённый в некоторой литературе, что дескать CRC не используется в TCP/IP ровно потому, что его трудно считать? Нет, он тривиально считается в аппаратуре, побитно...
Вообще-то TCP/IP начинался в условиях отсутствия такой аппаратуры. Хотя причину не держать таблицу в 512 байт я слабо понимаю. Может влиять ещё скорость вычисления.
Здравствуйте, MikelSV, Вы писали:
fk0>> Бред в состоянии белой горячки. MSV>Хмм, может быть. Я тут понял, что хочу через один порт гонять много отдельных потоков. Вот это действительно белая горячка, когда через 2 реальных соккета будут гоняться толпы виртуальных соединений.
Через 2 сокета можно поднять openvpn и гонять в ней чего угодно.
MSV>Простенькие вещи, типа пинга, возврата ip адреса и номера порта и возврата времени я приделал. они не требуют создания сессий и гоняются легко.
И ping с openvpn будет работать штатный и всё такое прочее.
"Как много весёлых ребят, и все делают велосипед..." (C)
Осознал, что написанный код устарел и выкинул его нафик. Пишу заново. Кстати, вполне успешно.
Удалось передать файл, пока на локальном компьютере.
Есть и контроллер пакетов, ошибки к сожалению пока не исправляет, но это дело времени.
Не совсем понял все рассуждения насчет crc. Нужен ли дополнительный контроль данных в пакете?
Понял, что не понял, как слать udp пакеты, при желании ими легко забьется канал и придется пересылать пакеты заново.
Полагаю будет установлено максимальное количество пакетов в "пути".
К удивлению обнаружил, что udp пакеты больше 1кб не доходят на локальном компьютере.
Чем меньше пакет, тем больший объем служебных данных получается.
В текущей реализации я постарался оптимизировать передаваемую информацию. Не знаю, получится ли создать хороший протокол и одновременно оптимизировать трафик. Похоже пора вспоминать, как делаются чудеса. ^_^
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Решил создать новый протокол на основе udp.
MSV>Возникающие вопросы: MSV>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
Из того, что вы очень смутно перечислили, я понял, что по сети всё-таки будут гулять UDP пакеты, а вы просто будете писать в них дополнительную служебную информацию и своей библиотекой её обрабатывать. Маршрутизаторы, в данном случае, видят обычные UDP пакеты. Точно так же, как маршрутизаторам пофиг на HTTP: они видят обычные TCP пакеты.
MSV>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно?
CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает.
MSV>Также хотелось бы услышать ваше мнение обо всей этой затее.
maxp вам выше правильно написал, что все велосипеды уже изобретены, но для исследования — конечно, нормальная затея. Только написав свой велосипед можно понять достоинства и недостатки чужих.
M>Для начала неплохо было бы определиться с предназначением протокола, M>потом ознакомиться с уже существующими.
Задача — передача данных и сообщений. создание более удобного протокола чем tcp и больше возможностей управления.
В этом протоколе будет реализована передача сообщений, которые на данный момент передавались по tcp.
M>И только потом, по всей видимости, станет ясно, что все возможные велосипеды M>в этой области уже придуманы и разработаны. Но сам процесс познания этой области M>весьма полезен.
Да, эта область открывает много новых и очень интересных возможностей.
MSV>>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
T>Из того, что вы очень смутно перечислили, я понял, что по сети всё-таки будут гулять UDP пакеты, а вы просто будете писать в них дополнительную служебную информацию и своей библиотекой её обрабатывать. Маршрутизаторы, в данном случае, видят обычные UDP пакеты. Точно так же, как маршрутизаторам пофиг на HTTP: они видят обычные TCP пакеты.
Вы кажется не поняли вопроса, вопрос был в разнице поведения маршрутизаторов при tcp и udp.
На данный момент я не знаю, как долго на маршрутизаторе будет открыт порт для udp соединения. (потестирую, когда напишу первый вариант протокола.)
MSV>>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно? T>CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает.
Опять не совсем то, CRC гарантирует правильность заголовка пакета или всего пакета?
MSV>>Также хотелось бы услышать ваше мнение обо всей этой затее. T>maxp вам выше правильно написал, что все велосипеды уже изобретены, но для исследования — конечно, нормальная затея. Только написав свой велосипед можно понять достоинства и недостатки чужих.
мой велосипед еще не изобретен А вообще, этом протоколе я увидел такие возможности, которые до сих пор только снились.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
MSV>>>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
T>>Из того, что вы очень смутно перечислили, я понял, что по сети всё-таки будут гулять UDP пакеты, а вы просто будете писать в них дополнительную служебную информацию и своей библиотекой её обрабатывать. Маршрутизаторы, в данном случае, видят обычные UDP пакеты. Точно так же, как маршрутизаторам пофиг на HTTP: они видят обычные TCP пакеты. MSV>Вы кажется не поняли вопроса, вопрос был в разнице поведения маршрутизаторов при tcp и udp. MSV>На данный момент я не знаю, как долго на маршрутизаторе будет открыт порт для udp соединения. (потестирую, когда напишу первый вариант протокола.)
Нет такого понятия "как долго открыт порт". Если речь о файрволе, то он открыт, пока админ его не закроет, то есть пока не создаст правило, по которому пакеты на такой-то порт дропаются или отправителю возвращается отказ (deny).
Если речь о таймаутах, то в UDP их просто нет. UDP — stateless протокол. Нет соединения, нет сессии. Есть просто передача пакетов.
MSV>>>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно? T>>CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает. MSV>Опять не совсем то, CRC гарантирует правильность заголовка пакета или всего пакета?
Здравствуйте, MikelSV, Вы писали:
MSV>А вообще, этом протоколе я увидел такие возможности, которые до сих пор только снились.
Вам снились? По громкости заявления напоминает Ваше предыдущее сообщение о создании фирмы
Ну, дерзайте. Создадите новый протокол, добавите его в стек, оформите патент и станете вторым Брином.
Здравствуйте, Temoto, Вы писали:
T>Нет такого понятия "как долго открыт порт". Если речь о файрволе, то он открыт, пока админ его не закроет, то есть пока не создаст правило, по которому пакеты на такой-то порт дропаются или отправителю возвращается отказ (deny). T>Если речь о таймаутах, то в UDP их просто нет. UDP — stateless протокол. Нет соединения, нет сессии. Есть просто передача пакетов.
Но порт то все равно открывается, на маршрутизаторе, типа NAT.
И маршрутизатор(NAT) воспринимает это как соединение, помнит, куда пересылать пакеты приходящие из интернета на этот порт.
меня беспокоит то, что посланный мне пакет будет отброшен из-за закрытия порта на маршрутизаторе по таймауту.
T>Заголовка и содержимого.
T>Вы бы почитали с чем будете работать, что-ли. Хотя бы на википедии, я уж не говорю про RFC768. T>http://en.wikipedia.org/wiki/User_Datagram_Protocol
Читал, но насчет CRC не совсем понял. ^_^
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Здравствуйте, Temoto, Вы писали:
T>>Нет такого понятия "как долго открыт порт". Если речь о файрволе, то он открыт, пока админ его не закроет, то есть пока не создаст правило, по которому пакеты на такой-то порт дропаются или отправителю возвращается отказ (deny). T>>Если речь о таймаутах, то в UDP их просто нет. UDP — stateless протокол. Нет соединения, нет сессии. Есть просто передача пакетов.
MSV>Но порт то все равно открывается, на маршрутизаторе, типа NAT. MSV>И маршрутизатор(NAT) воспринимает это как соединение, помнит, куда пересылать пакеты приходящие из интернета на этот порт. MSV>меня беспокоит то, что посланный мне пакет будет отброшен из-за закрытия порта на маршрутизаторе по таймауту.
Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
T>>Заголовка и содержимого.
T>>Вы бы почитали с чем будете работать, что-ли. Хотя бы на википедии, я уж не говорю про RFC768. T>>http://en.wikipedia.org/wiki/User_Datagram_Protocol MSV>Читал, но насчет CRC не совсем понял. ^_^
[q]UDP provides application multiplexing (via port numbers) and integrity verification (via checksum) of the header and payload.[q]
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, MikelSV, Вы писали:
MSV>>А вообще, этом протоколе я увидел такие возможности, которые до сих пор только снились.
А>Вам снились? По громкости заявления напоминает Ваше предыдущее сообщение о создании фирмы А>Ну, дерзайте. Создадите новый протокол, добавите его в стек, оформите патент и станете вторым Брином.
Опа, это который основатель гугла?
Ну реально интересные вещи, повесить на этот протокол HTTP. А так же методом пробивания ната создать сайт на закрытом динамическом ip.
Немного ушел в депрессию, чтобы выйти из нее занялся новой идеей. ^_^
Кстати, что значит добавить его в стек? (Стек протоколов полагаю.) Тоесть как?
Не вижу особого смысла. максимум, это создание в виде библиотеки.
И протокол не совсем похож на стандартные. планируется дополнительный поток. А сейчас кажется даже несколько.(для создания многопоточного сервера)
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, Temoto, Вы писали:
T>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
Хм, простой пример. DNS запрос, через UDP, который пройдет через нат.
Ответ приходит, значит в маршрутизаторе создалась сессия и он помнит, куда надо слать пакеты приходящие на тот порт.
T>Серьёзно, не понял?
Читал русский вариант.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Здравствуйте, Temoto, Вы писали:
T>>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
MSV>Хм, простой пример. DNS запрос, через UDP, который пройдет через нат. MSV>Ответ приходит, значит в маршрутизаторе создалась сессия и он помнит, куда надо слать пакеты приходящие на тот порт.
Здравствуйте, MikelSV, Вы писали:
MSV>Преимущества: MSV>* можно выкинуть select, и любые другие проверки. получение данных сразу по прибытию их.
Это как? Все равно вам как-то надо ждать прибывающего пакета. Единственная разница, в случае UDP короткое сообщение придет сразу целиком, а не частями, как в TCP.
Кстати, не советую очень-то рассчитывать на то, что большие фрагментированные UDP-пакеты будут свободно шнырять по всему Интернету. Запросто можете нарваться на роутер между вами и другой стороной, который будет их выкидывать при достижении некоторого (не слишком большого) предельного размера.
MSV>* управление разрывами, UDP уже порван, и разрывы ему не страшны.
Зато пакеты могут теряться, дуплицироваться и приходить не в том порядке, в котором они были посланы.
MSV>* больший контроль соединения, управление разрывами, появляется возможность посылки разных данных, как потока, так и сообщений. так же есть идея приделать возможность посылки пакетов, не требующих подтверждения доставки. MSV>+ очень заманчивые перспективы, появляется много идей, которые просто невозможны на tcp, управляемом системой.
Вам стоит посмотреть на SCTP. Он, правда, к сожалению не входит в стандартную венду...
MSV>Из проблем организовываются: MSV>* потребуется взять на себя часть функций системы и рулить всем этим делом.
Довольно изрядную часть. Осилите?
MSV>Возникающие вопросы: MSV>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
Домашнему роутеру более-менее все равно, если вы только не создаете новую пару внутренний порт/внешний адрес на каждый пакет. В последнем случае NAT'овская таблица быстро переполнится. Но во многих корпоративных сетях выход UDP наружу может быть закрыт, в то время как TCP доступен в более-менее либеральном режиме.
MSV>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно? MSV>* (Было что-то еще, надеюсь вспомню по ходу обсуждения, если таковое состоится. )
Контрольная сумма в UDP используется в точности такая же, как и в TCP. С единственным отличием: в UDP она является опциональной и при отправке пакета может быть отключена (физически при этом в пакете вместо контрольной суммы 0, что воспринимается принимающей стороной как просьба контрольную сумму не проверять).
MSV>Также хотелось бы услышать ваше мнение обо всей этой затее.
Дурацкая затея
Сначала определитесь с тем, какие проблемы вы собираетесь решать, потом уже выбирайте методы решения.
Здравствуйте, Temoto, Вы писали:
T>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
Для UDP есть NAT, причем обычнуе роутеры в среднем его поддерживают. Сессии как таковой нет, но роутер просто хранит в таблице в течении некоторого времени запись о том, что такой-то внутренний адрес:порт соответствует такому-то внешнему. Если в течении этого времени через такую ассоциацию траффика нет, ассоциация сгорает и освобождает место в таблице. Чтобы дырка в NAT'е не "заростала", достаточно посылать туда-обратно пакетик с некоторой периодичностью. Скажем, раз в минуту.
Кстати, в случае TCP все то же самое. Роутер не может рассчитывать на то, что ваш компутер вежливо позакрывает все сессии. Иначе в случае выключения компутера записи в таблице NAT'а болтались бы до морковкина заговения. Просто в случае TCP роутер может, увидив закрытие соединения, выкинуть запись из таблице раньше, не дожидаясь таймаута.
Здравствуйте, MikelSV, Вы писали:
MSV>Ну реально интересные вещи, повесить на этот протокол HTTP. А так же методом пробивания ната создать сайт на закрытом динамическом ip.
Пробивание ната требует координированных усилих двух сторон. Поэтому обычным бровсером на такой сайт не придешь, бровсер должен быть со встроенной натопробивалкой.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Temoto, Вы писали:
T>>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
Pzz>Для UDP есть NAT, причем обычнуе роутеры в среднем его поддерживают. Сессии как таковой нет, но роутер просто хранит в таблице в течении некоторого времени запись о том, что такой-то внутренний адрес:порт соответствует такому-то внешнему. Если в течении этого времени через такую ассоциацию траффика нет, ассоциация сгорает и освобождает место в таблице. Чтобы дырка в NAT'е не "заростала", достаточно посылать туда-обратно пакетик с некоторой периодичностью. Скажем, раз в минуту.
Pzz>Кстати, в случае TCP все то же самое. Роутер не может рассчитывать на то, что ваш компутер вежливо позакрывает все сессии. Иначе в случае выключения компутера записи в таблице NAT'а болтались бы до морковкина заговения. Просто в случае TCP роутер может, увидив закрытие соединения, выкинуть запись из таблице раньше, не дожидаясь таймаута.
Здравствуйте, MikelSV, Вы писали:
MSV>Решил создать новый протокол на основе udp.
Решил изобрести свой велосипед...
MSV>Преимущества: MSV>* можно выкинуть select, и любые другие проверки. получение данных сразу по прибытию их. MSV>* управление разрывами, UDP уже порван, и разрывы ему не страшны. MSV>* больший контроль соединения, управление разрывами, появляется возможность посылки разных данных, как потока, так и сообщений. так же есть идея приделать возможность посылки пакетов, не требующих подтверждения доставки. MSV>+ очень заманчивые перспективы, появляется много идей, которые просто невозможны на tcp, управляемом системой.
Ну да конечно, всё здорово и замечательно. А TCP лет 30 не менялся просто потому, что вокруг одни такие недогадливые дураки. И UDP примерно по той же причине существует (равно как и realiable UDP в RFC) -- дураки не понимают...
И через с натами фаерволы новый протокол сам волшебно как-то проникать начнёт...
MSV>Из проблем организовываются: MSV>* потребуется взять на себя часть функций системы и рулить всем этим делом.
Ну на фоне разработки собственноог протокола -- это вовсе не проблема. И реализуется это вовсе очень известным даже способом, на sourceforge есть миллионы и миллиарды студенческих программ это осуществляющих (raw socket).
MSV>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении? MSV>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно? MSV>* (Было что-то еще, надеюсь вспомню по ходу обсуждения, если таковое состоится. )
Судя по вопросам, вам бы эта, хоть Стивенса почитать для начала.
MSV>Также хотелось бы услышать ваше мнение обо всей этой затее.
Здравствуйте, Temoto, Вы писали:
T>CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает.
Жизненный опыт. CRC даёт хреновейшую защиту от "сбоев оборудования" при обрыве, когда с середины пакета и до конца все байты FFFF или 0000 не важно. А контрольная сумма замечательно работает. Кто-то всерьёз полагает, что бред повсеместно приведённый в некоторой литературе, что дескать CRC не используется в TCP/IP ровно потому, что его трудно считать? Нет, он тривиально считается в аппаратуре, побитно...
Хмм, может быть. Я тут понял, что хочу через один порт гонять много отдельных потоков. Вот это действительно белая горячка, когда через 2 реальных соккета будут гоняться толпы виртуальных соединений.
Простенькие вещи, типа пинга, возврата ip адреса и номера порта и возврата времени я приделал. они не требуют создания сессий и гоняются легко.
Наверно займусь сообщениями, для них тоже можно не делать виртуальных сессий, они как бы глобальные для соединения.
хм, и сдается мне на этом нужно закончить. полагаю будет сообщение с данными, то есть, в моем протоколе над tcp, (который я написал раньше), заложена возможность посылки набора сообщений, достаточных для работы с файлами: открытие, запись, чтение... потоки данных станут не более чем файлами. кстати, уже очень давно у меня есть код, позволяющий работать с виртуальными файлами внутри одной программы, а так же монтирование папок. К сожалению это все сделано внутри одной программы, до монтирования в систему я не дошел. В итоге, можно получать доступ к файлам на других компьютерах и вообще к любым источникам данных, как к обычным файлам на локальном компьютере. А если вам не нравится чистый поток, можно воспользоваться контейнером и погрузить туда данные в формате: ключ, значение. а для особых любителей извращений можно воспользоваться им для аналогичной передачи данных как в xml, с той же структурой.
В общем, белой и горячей у меня еще много.
Правда пожалуй кое что не доработано, это адресация. В размышлениях о которой я так и не пришел к хорошему решению.
Однако в данном случае адресация упадет до вида: ip:порт, что и решит все проблемы с ней.
Итого: данный протокол позволяет решить много различных проблем. И в случае успешной реализации позволят создавать готовые решения в передаче структурированных данных. (А стандартные протоколы, такие как HTTP и FTP можно легко переделать с использованием нового протокола.)
Вот такая вот она белая и пушистая и конечно же горячая.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Я тут понял, что хочу через один порт гонять много отдельных потоков. Вот это действительно белая горячка, когда через 2 реальных соккета будут гоняться толпы виртуальных соединений.
Не вижу ничего противоестественного в такой реализации.
Здравствуйте, MikelSV, Вы писали:
fk0>> Бред в состоянии белой горячки.
MSV>Хмм, может быть. Я тут понял, что хочу через один порт гонять много отдельных потоков. Вот это действительно белая горячка, когда через 2 реальных соккета будут гоняться толпы виртуальных соединений.
Ну а в чём проблема-то? Есть такие реализации. А вообще передать в начале сообщения номер виртуального потока — стоит копейки, а пользы целые вагоны. (Если это вообще нужно)
MSV>Простенькие вещи, типа пинга, возврата ip адреса и номера порта и возврата времени я приделал. они не требуют создания сессий и гоняются легко. MSV>Наверно займусь сообщениями, для них тоже можно не делать виртуальных сессий, они как бы глобальные для соединения.
Как только станет вопрос об адресации получателя сообщения, возникнет тот же самый идентификатор соединения (или сессии, в зависимости от стиля терминологии). Отличие будет только в том, где и как он выглядит.
MSV>В общем, белой и горячей у меня еще много.
Согласен.:) Вы даже если тут сделали что-то полезное — слишком сумбурно объясняете, чтобы можно было понять и оценить результат.
Здравствуйте, Pzz, Вы писали:
T>>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
Pzz>Для UDP есть NAT, причем обычнуе роутеры в среднем его поддерживают. Сессии как таковой нет, но роутер просто хранит в таблице в течении некоторого времени запись о том, что такой-то внутренний адрес:порт соответствует такому-то внешнему. Если в течении этого времени через такую ассоциацию траффика нет, ассоциация сгорает и освобождает место в таблице. Чтобы дырка в NAT'е не "заростала", достаточно посылать туда-обратно пакетик с некоторой периодичностью. Скажем, раз в минуту.
Pzz>Кстати, в случае TCP все то же самое. Роутер не может рассчитывать на то, что ваш компутер вежливо позакрывает все сессии. Иначе в случае выключения компутера записи в таблице NAT'а болтались бы до морковкина заговения. Просто в случае TCP роутер может, увидив закрытие соединения, выкинуть запись из таблице раньше, не дожидаясь таймаута.
Кстати. Есть ли реализации NAT, которые пытаются проверять живость соединения? Для TCP это могла бы быть посылка пакета без данных, просто с ACK. Для UDP мне нравится метод имени Sipura — на пакет из четырёх нулевых байт отвечается пустым пакетом.
Здравствуйте, netch80, Вы писали:
fk0>> Жизненный опыт. CRC даёт хреновейшую защиту от "сбоев оборудования" при обрыве, когда с середины пакета и до конца все байты FFFF или 0000 не важно.
N>Прошу примера. Мне сложно себе представить, чтобы правильно вычисленная и уложенная CRC не замечатала такие ситуации.
IP'ная контрольная сумма не замечает вставления/удаления последовательности из четного количества нулей (насчет FF'ов не поручусь).
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, fk0, Вы писали:
T>>>CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает. fk0>> Жизненный опыт. CRC даёт хреновейшую защиту от "сбоев оборудования" при обрыве, когда с середины пакета и до конца все байты FFFF или 0000 не важно. N>Прошу примера. Мне сложно себе представить, чтобы правильно вычисленная и уложенная CRC не замечатала такие ситуации.
Пример ниже. Прекрасно видно, что на случайных данных, на совершенно разных последовательностях (случайных), даже на коротких (несколко байт) пакетах можно нарваться на ситуацию, когда CRC совпадает, а хвост пакета (а то и весь пакет!) испорчен нулём или FF. Позапускай программу несколько раз (./a.out | less). Что характерно -- CRC должен быть равен заполняющему (всё портящему) байту. Так вот в реальном приборе, где проблемы были, там, догадайся...
Там CRC шёл в конце пакета
... и как следствие, портился "нужным" значением тоже.
Я для себя вывод сделал на всю жизнь. Ну кроме того, что долой самодельные протоколы... в данном случае протокол не самодельный. Нефиг CRC в конец закладывать или нужно иметь в концец чёткий маркер конца пакета. Да, длина там первым байтом в пакете ещё. CRC пакета с нулевой длиной -- правильно, ноль. Протокол, повторюсь, не самодельный, это проблема всего SMBUS (переименованный интелом I2C). И когда есть "обрывы" с заполнением конца FF-ами (характерная особенность I2C) и когда пакетов тысячи в секунду -- это проблема.
Да, конечно, 8-битный CRC надёжно защищает только от 8-и ошибочных битов подряд... 16-битный, соответственно, от 16-и. А там посылки короткие, по десятку байт, в протоколе 32 байта максимум. И что характерно, в такой ситуации 16-битовая сумма позволяет посылки короче 256 байт без ошибок...
fk0>> А контрольная сумма замечательно работает. Кто-то всерьёз полагает, что бред повсеместно приведённый в некоторой литературе, что дескать CRC не используется в TCP/IP ровно потому, что его трудно считать? Нет, он тривиально считается в аппаратуре, побитно... N>Вообще-то TCP/IP начинался в условиях отсутствия такой аппаратуры. Хотя причину не держать таблицу в 512 байт я слабо понимаю. Может влиять ещё скорость вычисления.
Вообще-то CRC считается и бестабличными методами достаточно быстро, если такая задача стоит. Опять же смотри пример. Все возражения "почему не 16-32 бита" -- потому что блоки не по 4 килобайта, а по десятку байт. А 16 бит принципиально ситуацию тут не изменит вообще.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, netch80, Вы писали:
fk0>>> Жизненный опыт. CRC даёт хреновейшую защиту от "сбоев оборудования" при обрыве, когда с середины пакета и до конца все байты FFFF или 0000 не важно.
N>>Прошу примера. Мне сложно себе представить, чтобы правильно вычисленная и уложенная CRC не замечатала такие ситуации.
Pzz>IP'ная контрольная сумма не замечает вставления/удаления последовательности из четного количества нулей (насчет FF'ов не поручусь).
Стоп-стоп. Кирилл как раз говорит что CRC даёт слабую защиту (а контрольная сумма IP — достаточную). Ты приводишь пример на IP'шную сумму, хорошо. Но это как раз в противоречие его тезису. Я же хочу узнать, откуда такие странные выводы. То ли Кирилл оговорился и хотел сказать наоборот, то ли это противоречит тому, что я знал про эти средства.
Здравствуйте, Pzz, Вы писали:
fk0>>> Жизненный опыт. CRC даёт хреновейшую защиту от "сбоев оборудования" при обрыве, когда с середины пакета и до конца все байты FFFF или 0000 не важно. N>>Прошу примера. Мне сложно себе представить, чтобы правильно вычисленная и уложенная CRC не замечатала такие ситуации. Pzz>IP'ная контрольная сумма не замечает вставления/удаления последовательности из четного количества нулей (насчет FF'ов не поручусь).
Вставка, удаление (кроме как с конца) и перестановка -- что-то по физическим причинам маловероятное в последовательном протоколе. А вот "обрывы" с замещением данных на 0 или 1, или укорачивание пакета (удаление с конца), ну и просто искажение битов -- запросто.
Здравствуйте, fk0, Вы писали:
fk0> Пример ниже. Прекрасно видно, что на случайных данных, на совершенно разных последовательностях (случайных), даже на коротких (несколко байт) пакетах можно нарваться на ситуацию, когда CRC совпадает, а хвост пакета (а то и весь пакет!) испорчен нулём или FF. Позапускай программу несколько раз (./a.out | less). Что характерно -- CRC должен быть равен заполняющему (всё портящему) байту. Так вот в реальном приборе, где проблемы были, там, догадайся...
Во-первых, с самого начала: твой пример попросту с багом. Если его исправить как следует:
$ diff -u m.c.00 m.c
--- m.c.orig
+++ m.c
@@ -67,7 +67,7 @@
/* compute CRC of damaged packet */
ncrc=0;
for (n=0; n<plen; n++)
- ncrc=crc_byte(copy[n], crc);
+ ncrc=crc_byte(copy[n], ncrc);
/* check if crc doesn't protect data integrity */
if (crc != ncrc) continue;
то у меня получается в самом коротком случае 3 байта испорченных, иногда 4, обычно же оно не находит случаев короче чем 8 байт. Для CRC-8 это очень хороший результат. А твой пример умудряется находить даже последовательности с изменением одного последнего байта, что заведомо показывает на ошибочность твоего кода (собственно почему я и стал рыть).
Далее по частям программы:
fk0>/* compute CRC-8 for SMBUS (x^8 + x^2 + x + 1) */ fk0>uint_fast8_t crc_byte(uint_fast8_t byte, uint_fast8_t crc) fk0>{ fk0>uint_fast8_t b; fk0> b=byte^crc; fk0> if (b&(1<<0)) crc^=0x7; fk0> if (b&(1<<1)) crc^=0xe; fk0> if (b&(1<<2)) crc^=0x1c; fk0> if (b&(1<<3)) crc^=0x38; fk0> if (b&(1<<4)) crc^=0x70; fk0> if (b&(1<<5)) crc^=0xe0; fk0> if (b&(1<<6)) crc^=0xc7; fk0> if (b&(1<<7)) crc^=0x89; fk0> return crc; fk0>}
Не знаю, что ты здесь хотел нарисовать, но это никак не CRC в обычном понимании.
В обычном было бы примерно так:
uint_fast8_t crc_byte(uint_fast8_t byte, uint_fast8_t crc)
{
uint_fast8_t old = crc;
crc = byte;
if (old & (1<<0)) crc ^= 0x07;
... аналогичные варианты для остальных битов ...
return crc;
}
Может, твой код преобразуется в то, что делается по классике, но тут получается как минимум смещение на байт, и я с ходу не берусь предсказать результаты этого смещения и степень устойчивости результата.
Откуда код? Ты это взял из спецификации SMBus? Кстати, там точно передача начинается со старшего бита?
fk0> Вообще-то CRC считается и бестабличными методами достаточно быстро, если такая задача стоит. Опять же смотри пример. Все возражения "почему не 16-32 бита" -- потому что блоки не по 4 килобайта, а по десятку байт. А 16 бит принципиально ситуацию тут не изменит вообще.
Думаю, таки изменит. Не зря на Ethernet при типичном размере пакета в пару сотен байт уже применялся CRC-32.
Но твоя ситуация вообще-то показывает контекст не для CRC. CRC предназначен для случаев именно одиночных независимых искажений потока (изменения битов, выпадения/добавления целых байт). Причём на SMBus, аналогично RS-232, невозможно держать AFAIK линию данных всё время на одном уровне — потому что тогда не будут видны границы байтов. Ситуация, когда хвост пакета целиком становится битами одного значения, означает сбой уже в кодере или декодере протокола, а не помеху/сбой на линии. Такие вещи должны отлавливаться на другом уровне и обвинять CRC в их неотлове — нелепость.
Если ты хочешь проверить CRC на корректность детекта в условиях, в которых он предназначен работать — меняй произвольно 1 из ~100 байтов не обязательно в хвосте.
Здравствуйте, fk0, Вы писали:
Pzz>>IP'ная контрольная сумма не замечает вставления/удаления последовательности из четного количества нулей (насчет FF'ов не поручусь).
fk0> Вставка, удаление (кроме как с конца) и перестановка -- что-то по физическим причинам маловероятное в последовательном протоколе.
На RS-232 — сколько угодно. Прошёл левый импульс — приняли за стартовый бит.
fk0> А вот "обрывы" с замещением данных на 0 или 1,
Смотрю на типичную диаграмму I2C/SMBus, видим, что приёмник должен подтвердить приём — и что при этом линия SDA должна перейти в низкое состояние и обратно. То есть ситуация с тем, что кто-то замкнул линию, приведёт к стопу любых передач — они не смогут продолжиться. Максимум повреждения — один байт — лечится CRC.
Или у тебя суперклиенты на шине, которые в состоянии добавлять нули в чужую передачу именно в моменты передачи битов данных? Ну тогда это уже какая-то совершенно безумная ситуация.
fk0> или укорачивание пакета (удаление с конца), ну и просто искажение битов -- запросто.
Обычное искажение детектится CRC с хорошей надёжностью. Укорачивание должно опознаваться в рамках протокола.
В общем, не вижу, как реально можно получить такой кошмар, как ты рисовал.
Здравствуйте, MikelSV, Вы писали:
MSV>Решил создать новый протокол на основе udp. MSV>Преимущества: MSV>* можно выкинуть select, и любые другие проверки. получение данных сразу по прибытию их.
Select тут ни при чём. Если это намёк на возможность посылать крупными порциями, то 1) за 64K вообще не вылезешь, 2) проблема с MTU.
MSV>* управление разрывами, UDP уже порван, и разрывы ему не страшны.
В случае NAT или stateful firewall — ещё как страшны.
MSV>* больший контроль соединения, управление разрывами, появляется возможность посылки разных данных, как потока, так и сообщений. так же есть идея приделать возможность посылки пакетов, не требующих подтверждения доставки.
На BEEP смотрели?
MSV>+ очень заманчивые перспективы, появляется много идей, которые просто невозможны на tcp, управляемом системой.
Например?
MSV>Возникающие вопросы: MSV>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
Согласно настройкам.
MSV>Было бы неплохо обсудить саму техническую сторону. вопросов с организацией много, и мозги соображают достаточно медленно. MSV>Так же уже видны проблемы в безопасности(в основном при подделке пакетов), что радости не добавляет.
Присоединяюсь к предложению брать готовое. SCTP, BEEP...
Здравствуйте, netch80, Вы писали:
N>Кстати. Есть ли реализации NAT, которые пытаются проверять живость соединения? Для TCP это могла бы быть посылка пакета без данных, просто с ACK. Для UDP мне нравится метод имени Sipura — на пакет из четырёх нулевых байт отвечается пустым пакетом.
В смысле, бывает ли так, чтобы коробка с NAT'ом пыталась какими-то активными действиями проверить, живо ли еще соединение? Не знаю. А зачем это коробке?
Здравствуйте, netch80, Вы писали:
N>Стоп-стоп. Кирилл как раз говорит что CRC даёт слабую защиту (а контрольная сумма IP — достаточную). Ты приводишь пример на IP'шную сумму, хорошо. Но это как раз в противоречие его тезису. Я же хочу узнать, откуда такие странные выводы. То ли Кирилл оговорился и хотел сказать наоборот, то ли это противоречит тому, что я знал про эти средства.
По-моему, он хотел сказать наоборот. IP'ную сумму народ иногда тоже называет CRC'ом. Ума ни преложу, почему...
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, fk0, Вы писали:
fk0>> Пример ниже. Прекрасно видно, что на случайных данных, на совершенно разных последовательностях (случайных), даже на коротких (несколко байт) пакетах можно нарваться на ситуацию, когда CRC совпадает, а хвост пакета (а то и весь пакет!) испорчен нулём или FF. Позапускай программу несколько раз (./a.out | less). Что характерно -- CRC должен быть равен заполняющему (всё портящему) байту. Так вот в реальном приборе, где проблемы были, там, догадайся...
N>Во-первых, с самого начала: твой пример попросту с багом. Если его исправить как следует: N>- ncrc=crc_byte(copy[n], crc); N>+ ncrc=crc_byte(copy[n], ncrc);
N>то у меня получается в самом коротком случае 3 байта испорченных, иногда 4, обычно же оно не находит случаев короче чем 8 байт. Для CRC-8 это очень хороший результат. А твой пример умудряется находить даже последовательности с изменением одного последнего байта, что заведомо показывает на ошибочность твоего кода (собственно почему я и стал рыть).
Исправил. Так ведь получается. Вот пример для 1000 запусков:
Как и ожидалось, ошибки не может быть только для однобайтовых пакетов. К слову, функция crc_byte здесь применена медленная (побитная) на всякий случай.
N>Далее по частям программы:
fk0>>/* compute CRC-8 for SMBUS (x^8 + x^2 + x + 1) */ fk0>>uint_fast8_t crc_byte(uint_fast8_t byte, uint_fast8_t crc) fk0>>{ fk0>>uint_fast8_t b; fk0>> b=byte^crc; fk0>> if (b&(1<<0)) crc^=0x7; fk0>> if (b&(1<<1)) crc^=0xe; fk0>> if (b&(1<<2)) crc^=0x1c; fk0>> if (b&(1<<3)) crc^=0x38; fk0>> if (b&(1<<4)) crc^=0x70; fk0>> if (b&(1<<5)) crc^=0xe0; fk0>> if (b&(1<<6)) crc^=0xc7; fk0>> if (b&(1<<7)) crc^=0x89; fk0>> return crc; fk0>>} N>Не знаю, что ты здесь хотел нарисовать, но это никак не CRC в обычном понимании.
Это CRC с указанным полиномом и его результат для любых входных значений полностью совпадает с побитным алгоритмом CRC. Указанный полином на сайте smbus.org... Указанные коэффициенты для ксорки берутся из результатов вычисления таблицы CRC побитным алгоритмом и взятия каждого 2^N-го члена для N=0..7. Это оптимизированный алгоритм просто. И, кстати, на мелких контроллерах он может работать быстрее табличного (на гарвардских архитектурах доступ к данным в программной памяти -- медленный).
Тут закралась действительно ошибка и CRC считается неправильно:
Вот он, гарантированно работающий, но медленный (к слову, в приборе был он, не оптимизированный):
uint_fast8_t smbus_crc_byte(uint_fast8_t byte, uint_fast8_t crc)
{
uint_fast8_t y=8;
do {
if ((byte^crc)&0x80) crc<<=1, crc^=0x7;
else crc<<=1;
byte<<=1;
} while (--y);
return crc;
}
Результаты вычислений совпадают (после исправления crc=0).
N>Может, твой код преобразуется в то, что делается по классике, но тут получается как минимум смещение на байт, и я с ходу не берусь предсказать результаты этого смещения и степень устойчивости результата.
См. выше, моя ошибка. Алгоритм переделывался с другого, для Maxim (бывший Dallas) 1-Wire, там биты в другую сторону сдвигаются, оттого и...
N>Откуда код? Ты это взял из спецификации SMBus? Кстати, там точно передача начинается со старшего бита?
Там точно (в I2C вообще) передача 7-м битом вперёд. Вот в 1-Wire -- наоборот, начиная с младшего.
IMHO начиная со старшего правильнее. Их удобнее на осциллографе разглядывать -- сразу можно в голове байт сложить...
fk0>> Вообще-то CRC считается и бестабличными методами достаточно быстро, если такая задача стоит. Опять же смотри пример. Все возражения "почему не 16-32 бита" -- потому что блоки не по 4 килобайта, а по десятку байт. А 16 бит принципиально ситуацию тут не изменит вообще. N>Думаю, таки изменит. Не зря на Ethernet при типичном размере пакета в пару сотен байт уже применялся CRC-32.
N>Но твоя ситуация вообще-то показывает контекст не для CRC. CRC предназначен для случаев именно одиночных независимых искажений потока (изменения битов, выпадения/добавления целых байт).
Увы и ах. Именно так, именно для того он и предназначен. И в RS-232 будет замечательно работать. А где пакетная передача с обрывами посереди пакета и заполнением конца пакета одинаковым битом -- не канает CRC.
N> Причём на SMBus, аналогично RS-232, невозможно держать AFAIK линию данных всё время на одном уровне — потому что тогда не будут видны границы байтов. Ситуация, когда хвост пакета целиком становится битами одного значения, означает сбой уже в кодере или декодере протокола, а не помеху/сбой на линии. Такие вещи должны отлавливаться на другом уровне и обвинять CRC в их неотлове — нелепость.
Ничего подобного. Ситуация там такая: приём данных мастером, слейв отвалился по электрическим причинам (стоп-сигнал увидел и т.п.) На шине соответственно единица (обеспечивается резистором подтяжки) всё время. А мастер так уверенно читает все биты до конца пакета и *никак* не может знать, что слейв уже обмен закончил. Между байтами разделения в I2C нет, как и границ байтов в данном случае. В случае когда мастер записывал бы -- да, разделение есть, слейв должен на каждый байт ACKnowledge нулевым битом давать. А тут мастер должен ACK давать -- ну вот он и даёт, и читает дальше... Это в значительной степени проблема шины и протокола SMBUS (обязательный нулевой бит в конце пакета кардинально решал бы проблему).
N>Если ты хочешь проверить CRC на корректность детекта в условиях, в которых он предназначен работать — меняй произвольно 1 из ~100 байтов не обязательно в хвосте.
Если я поменяю 1 байт -- CRC-8 это всегда обнаружит. Надо 2 менять.
Кстати ещё пример неправильного применения CRC -- контрольный код записи в FLASH-памяти. Догадываешься уже почему? Ровно та же проблема. Массовое FF-чивание отдельных блоков. Контрольная сумма подходящей разрядности (весьма небольшой) опять же справляется гарантировано и это очевидно математически. Хотя и не справляется так хорошо с единичными сбоями, как CRC.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, fk0, Вы писали:
Pzz>>>IP'ная контрольная сумма не замечает вставления/удаления последовательности из четного количества нулей (насчет FF'ов не поручусь).
fk0>> Вставка, удаление (кроме как с конца) и перестановка -- что-то по физическим причинам маловероятное в последовательном протоколе. N>На RS-232 — сколько угодно. Прошёл левый импульс — приняли за стартовый бит.
Если в этот момент не было уже передачи. И скорей не RS-232 в голом виде, а модем -- вот там да, запросто вставки бывают, да и замены, и удаления...
fk0>> А вот "обрывы" с замещением данных на 0 или 1, N>Смотрю на типичную диаграмму I2C/SMBus, видим, что приёмник должен подтвердить приём — и что при этом линия SDA должна перейти в низкое состояние и обратно. То есть ситуация с тем, что кто-то замкнул линию, приведёт к стопу любых передач — они не смогут продолжиться. Максимум повреждения — один байт — лечится CRC.
Разрыв линии при приёме мастером из слейва. Клок всегда выдаёт мастер (а не тот кто передаёт, в данном случае это слейв). Можно слейв из разъёма вырвать физически, можно добиться чтоб он сам отвалился по своей инициативе в условиях сильного искажения данных на шине.
N>Или у тебя суперклиенты на шине, которые в состоянии добавлять нули в чужую передачу именно в моменты передачи битов данных? Ну тогда это уже какая-то совершенно безумная ситуация.
Это кстати запросто. В длинной шине и сигналы "звенят", и 100 вольт на несколько наносекунд появлялось при включении двигателей... биты изгибались. Но это всегда ловилось на CRC, а вот обрывы -- нет.
fk0>> или укорачивание пакета (удаление с конца), ну и просто искажение битов -- запросто. N>Обычное искажение детектится CRC с хорошей надёжностью. Укорачивание должно опознаваться в рамках протокола. N>В общем, не вижу, как реально можно получить такой кошмар, как ты рисовал.
Этот кошмар реально был получен, как говорится проверено электроникой, практически. И он присутствует везде, где I2C и его производные.
Здравствуйте, Pepel, Вы писали:
MSV>>Решил создать новый протокол на основе udp.
P>неудачный выбор, при высокой утилизации сетки udp шные пакеты отбрасываются тучами,
UDP или вообще IP? Что-то я не замечал в алгоритмах контроля трафика какого-то особого предпочтения UDP.
P> никакой мало-мальськи устойчивый сервис вы на udp не предложите
Ну так и на IP его не предложить. А вот так, как сейчас работает IP (включая TCP) — можно сделать и на UDP без проблем. Только процессорных затрат больше (и трафика процентов на 5).
fk0>>>> Жизненный опыт. CRC даёт хреновейшую защиту от "сбоев оборудования" при обрыве, когда с середины пакета и до конца все байты FFFF или 0000 не важно. N>>>Прошу примера. Мне сложно себе представить, чтобы правильно вычисленная и уложенная CRC не замечатала такие ситуации. Pzz>>IP'ная контрольная сумма не замечает вставления/удаления последовательности из четного количества нулей (насчет FF'ов не поручусь).
Открою секрет: CRC и IP суммы ваще не дают никаких защит. То есть в том плане что полагаться на них попросту нельзя. Единственное их назначение — уменьшить нагрузку на оборудование в том случае когда из-за перегрузки или других причин идет куча левых пакетов. И все. По сути это оптимизация траффика, а не какая-то "защита".
Сама реализация контроля целостности подразумевает что никаких гарантий здесь ждать не надо и спорить не о чем. И если они вам нужны — делайте контроль сами, причем на том уровне надежности, который лично вам и нужен. Если вам реально важно чтобы данные дошли неполоманными — то без MD5/SHA? вам по любому уже не обойтись. А если уж речь заходит о MiM атаках — то велкам to SSL. А реализацию таких алгоритмов _внутри_ для всех протоколов tcp/ip стек себе позволить не может, даже с современным железом. Да и не зачем это — всегда правильнее строить протоколы on top друг друга, а не городить все в одном месте. Особенно учитывая, что такой мегаконтроль далеко не всем прикладным протоколам требуется.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
Pzz>>>IP'ная контрольная сумма не замечает вставления/удаления последовательности из четного количества нулей (насчет FF'ов не поручусь). O>Открою секрет: CRC и IP суммы ваще не дают никаких защит. То есть в том плане что полагаться на них попросту нельзя. Единственное их назначение — уменьшить нагрузку на оборудование в том случае когда из-за перегрузки или других причин идет куча левых пакетов. И все. По сути это оптимизация траффика, а не какая-то "защита".
Ерунда. 16-битная контрольная сумма дает защиту, уменьшая вероятность незамеченных ошибок до 2^-16. MD5 — до 2^-128 и т.п. Что из этого выбрать, зависит от того, какая степень защиты нужна для вашей задачи и сколько вы за это готовы заплатить — в т.ч. в терминах вычислительных ресурсов. Вообще, говорить о защите вне контекста того, от чего мы защищаемся и зачем, некорректно.
Кстати, винчестеры (те, которые жесткие диски) полагаются на CRC32, считая, что вероятность аппаратной ошибки чтения, умноженная на 2^-32 достаточно мала для практических целей.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Pepel, Вы писали:
MSV>>>Решил создать новый протокол на основе udp.
P>>неудачный выбор, при высокой утилизации сетки udp шные пакеты отбрасываются тучами,
N>UDP или вообще IP? Что-то я не замечал в алгоритмах контроля трафика какого-то особого предпочтения UDP.
значит плохо наблюдали, udp пакеты при загрузки сети прост херятся без зазрения совести
Pzz>>>>IP'ная контрольная сумма не замечает вставления/удаления последовательности из четного количества нулей (насчет FF'ов не поручусь). O>>Открою секрет: CRC и IP суммы ваще не дают никаких защит. То есть в том плане что полагаться на них попросту нельзя. Единственное их назначение — уменьшить нагрузку на оборудование в том случае когда из-за перегрузки или других причин идет куча левых пакетов. И все. По сути это оптимизация траффика, а не какая-то "защита". Pzz>Ерунда. 16-битная контрольная сумма дает защиту, уменьшая вероятность незамеченных ошибок до 2^-16. MD5 — до 2^-128 и т.п. Что из этого выбрать, зависит от того, какая степень защиты нужна для вашей задачи и сколько вы за это готовы заплатить — в т.ч. в терминах вычислительных ресурсов. Вообще, говорить о защите вне контекста того, от чего мы защищаемся и зачем, некорректно.
2^16 это 65536. Умножаем на MTU (~1.5kb) — получаем 100мб данных до появления ошибки, что по сути фигня. Потому это не защита а лишь _оптимизация_ трафика.
Pzz>Кстати, винчестеры (те, которые жесткие диски) полагаются на CRC32, считая, что вероятность аппаратной ошибки чтения, умноженная на 2^-32 достаточно мала для практических целей.
Это они в протоколе передачи разве что на CRC32 полагаются. При хранении данных давно используются более навороченные методы контроля/восстановления типа кода Рида-Соломона.
Как много веселых ребят, и все делают велосипед...
N>>UDP или вообще IP? Что-то я не замечал в алгоритмах контроля трафика какого-то особого предпочтения UDP. P>значит плохо наблюдали, udp пакеты при загрузки сети прост херятся без зазрения совести
Все IP пакеты херяться без зазрения совести.
Кстати ICMP имеет предпочтение над остальными пакетами, потому он херится меньше. Но кастомная реализация стримового протокола поверх UDP/IP в этом смысле будет ничем не лучше и не хуже TCP/IP. Разве что будет менее быстрой за счет большего количества служебных данных в каждом пакете.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>2^16 это 65536. Умножаем на MTU (~1.5kb) — получаем 100мб данных до появления ошибки, что по сути фигня. Потому это не защита а лишь _оптимизация_ трафика.
Ваша формула, очевидно, неверна, поскольку никак не учитывает вероятность появления ошибки в одном фрейме. А она, эта вероятность, очень зависит от того, каким физическим методом передаются данные.
O>Это они в протоколе передачи разве что на CRC32 полагаются. При хранении данных давно используются более навороченные методы контроля/восстановления типа кода Рида-Соломона.
Ну там по-моему все равно 32-битные коды. Рид-Соломон хорош не тем, что он лучше детектирует ошибки (лучше или хуже, зависит от степени избыточности, а это configurable parameter), а тем, что позволяет не только заметить, но и исправить.
Здравствуйте, ononim, Вы писали:
Pzz>>Ерунда. 16-битная контрольная сумма дает защиту, уменьшая вероятность незамеченных ошибок до 2^-16. MD5 — до 2^-128 и т.п. Что из этого выбрать, зависит от того, какая степень защиты нужна для вашей задачи и сколько вы за это готовы заплатить — в т.ч. в терминах вычислительных ресурсов. Вообще, говорить о защите вне контекста того, от чего мы защищаемся и зачем, некорректно. O>2^16 это 65536. Умножаем на MTU (~1.5kb) — получаем 100мб данных до появления ошибки, что по сути фигня. Потому это не защита а лишь _оптимизация_ трафика.
Надо ещё умножить на вероятность появления ошибки в пакете. Она меньше 10^-9.
Здравствуйте, ononim, Вы писали:
N>>>UDP или вообще IP? Что-то я не замечал в алгоритмах контроля трафика какого-то особого предпочтения UDP. P>>значит плохо наблюдали, udp пакеты при загрузки сети прост херятся без зазрения совести O>Все IP пакеты херяться без зазрения совести. O>Кстати ICMP имеет предпочтение над остальными пакетами, потому он херится меньше. Но кастомная реализация стримового протокола поверх UDP/IP в этом смысле будет ничем не лучше и не хуже TCP/IP. Разве что будет менее быстрой за счет большего количества служебных данных в каждом пакете.
да, естессно, все херятся, но если в TCP мы все таки худо-бедно данные выскребаем, то на UDP все тихой сапой херится и сервис ни сном ни духом
O>>2^16 это 65536. Умножаем на MTU (~1.5kb) — получаем 100мб данных до появления ошибки, что по сути фигня. Потому это не защита а лишь _оптимизация_ трафика. Pzz>Ваша формула, очевидно, неверна, поскольку никак не учитывает вероятность появления ошибки в одном фрейме. А она, эта вероятность, очень зависит от того, каким физическим методом передаются данные.
В худших условиях — ошибочных фреймов столько же если не больше как в обычных. Особенно если в сети появляется глючный девайс.
O>>Это они в протоколе передачи разве что на CRC32 полагаются. При хранении данных давно используются более навороченные методы контроля/восстановления типа кода Рида-Соломона. Pzz>Ну там по-моему все равно 32-битные коды. Рид-Соломон хорош не тем, что он лучше детектирует ошибки (лучше или хуже, зависит от степени избыточности, а это configurable parameter), а тем, что позволяет не только заметить, но и исправить.
"используются более навороченные методы контроля/восстановления"
мои же слова
Как много веселых ребят, и все делают велосипед...
N>>>>UDP или вообще IP? Что-то я не замечал в алгоритмах контроля трафика какого-то особого предпочтения UDP. P>>>значит плохо наблюдали, udp пакеты при загрузки сети прост херятся без зазрения совести O>>Все IP пакеты херяться без зазрения совести. O>>Кстати ICMP имеет предпочтение над остальными пакетами, потому он херится меньше. Но кастомная реализация стримового протокола поверх UDP/IP в этом смысле будет ничем не лучше и не хуже TCP/IP. Разве что будет менее быстрой за счет большего количества служебных данных в каждом пакете. P>да, естессно, все херятся, но если в TCP мы все таки худо-бедно данные выскребаем, то на UDP все тихой сапой херится и сервис ни сном ни духом
эээ. вы не выскабете в TCP, их выскребает сам TCP. Причем там применяются весьма хитрые алгоритмы контроля — к примеру если потерь пакетов дофига то наверно стоит слать пореже пакеты, ну и понятное дело перепосылать не дошедшие куски, реорганизовывать в нужном порядке дошедие и тд и тп
С UDP вам придется все это самому реализовывать.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
Pzz>>Ваша формула, очевидно, неверна, поскольку никак не учитывает вероятность появления ошибки в одном фрейме. А она, эта вероятность, очень зависит от того, каким физическим методом передаются данные. O>В худших условиях — ошибочных фреймов столько же если не больше как в обычных. Особенно если в сети появляется глючный девайс.
Т.е., ваша формула описывает частный случай, когда данные передаются с помощью глючного девайса, делающего ошибку в каждом фрейме?
Pzz>>Ну там по-моему все равно 32-битные коды. Рид-Соломон хорош не тем, что он лучше детектирует ошибки (лучше или хуже, зависит от степени избыточности, а это configurable parameter), а тем, что позволяет не только заметить, но и исправить. O>"используются более навороченные методы контроля/восстановления" O>мои же слова
Не важно. Если вы используете N бит дополнительной информации, вы можете уменьшить вероятность того, что ошибка пройдет незамеченной, не более, чем в 2^N раз, сколь бы навороченные методы вы не использовали.
Просто Рид-Соломон (и подобные error correction codes) позволяют не только заметить ошибку, но и исправить. Для винчестера это полезная фича, вряд ли вас порадует замеченная, но неисправленная ошибка Для сети эта фича менее важна, поскольку вместо исправления ошибки можно полагаться на retransmit.
Pzz>>>Ваша формула, очевидно, неверна, поскольку никак не учитывает вероятность появления ошибки в одном фрейме. А она, эта вероятность, очень зависит от того, каким физическим методом передаются данные. O>>В худших условиях — ошибочных фреймов столько же если не больше как в обычных. Особенно если в сети появляется глючный девайс. Pzz>Т.е., ваша формула описывает частный случай, когда данные передаются с помощью глючного девайса, делающего ошибку в каждом фрейме?
Она описывает самый крайний случай. Другой крайний случай — ошибок ваще нет — в таком случае и чексума не нужна
Pzz>>>Ну там по-моему все равно 32-битные коды. Рид-Соломон хорош не тем, что он лучше детектирует ошибки (лучше или хуже, зависит от степени избыточности, а это configurable parameter), а тем, что позволяет не только заметить, но и исправить. O>>"используются более навороченные методы контроля/восстановления" O>>мои же слова Pzz>Не важно. Если вы используете N бит дополнительной информации, вы можете уменьшить вероятность того, что ошибка пройдет незамеченной, не более, чем в 2^N раз, сколь бы навороченные методы вы не использовали. Pzz>Просто Рид-Соломон (и подобные error correction codes) позволяют не только заметить ошибку, но и исправить. Для винчестера это полезная фича, вряд ли вас порадует замеченная, но неисправленная ошибка Для сети эта фича менее важна, поскольку вместо исправления ошибки можно полагаться на retransmit.
Ну как бы ошибки на винчестерах тоже не являются чемто необычным — попробуйте на слегка разогнанной но с виду "стабильно" работающей системе покопировать файлы гиг на 10 а потом сверить их после перезагрузки — очень удивитесь. Потому даже на винчестерах действительно критичные к потерям файлы следует дублировать и хранить с хэшами.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
Pzz>>Т.е., ваша формула описывает частный случай, когда данные передаются с помощью глючного девайса, делающего ошибку в каждом фрейме? O>Она описывает самый крайний случай. Другой крайний случай — ошибок ваще нет — в таком случае и чексума не нужна
Это и называется "частный случай".
O>Ну как бы ошибки на винчестерах тоже не являются чемто необычным — попробуйте на слегка разогнанной но с виду "стабильно" работающей системе покопировать файлы гиг на 10 а потом сверить их после перезагрузки — очень удивитесь. Потому даже на винчестерах действительно критичные к потерям файлы следует дублировать и хранить с хэшами.
Это у вас не ошибка винчестера, а память сбоит. Не надо разгонять машину настолько.
O>>Ну как бы ошибки на винчестерах тоже не являются чемто необычным — попробуйте на слегка разогнанной но с виду "стабильно" работающей системе покопировать файлы гиг на 10 а потом сверить их после перезагрузки — очень удивитесь. Потому даже на винчестерах действительно критичные к потерям файлы следует дублировать и хранить с хэшами. Pzz>Это у вас не ошибка винчестера, а память сбоит. Не надо разгонять машину настолько.
Это не у меня. Я просто такое видел, причем не раз.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Pepel, Вы писали:
MSV>>>>Решил создать новый протокол на основе udp. P>>>неудачный выбор, при высокой утилизации сетки udp шные пакеты отбрасываются тучами, N>>UDP или вообще IP? Что-то я не замечал в алгоритмах контроля трафика какого-то особого предпочтения UDP. P>значит плохо наблюдали, udp пакеты при загрузки сети прост херятся без зазрения совести
Вы явно не читаете того, что Вам пишут.
У средств ограничения трафика нет никакого предпочтения UDP. Херятся все одинаково.
А если Вы применяете UDP на управляющем или наливном трафике без контроля доставки — это исключительно Ваша ошибка.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, ononim, Вы писали:
Pzz>>>Ерунда. 16-битная контрольная сумма дает защиту, уменьшая вероятность незамеченных ошибок до 2^-16. MD5 — до 2^-128 и т.п. Что из этого выбрать, зависит от того, какая степень защиты нужна для вашей задачи и сколько вы за это готовы заплатить — в т.ч. в терминах вычислительных ресурсов. Вообще, говорить о защите вне контекста того, от чего мы защищаемся и зачем, некорректно. O>>2^16 это 65536. Умножаем на MTU (~1.5kb) — получаем 100мб данных до появления ошибки, что по сути фигня. Потому это не защита а лишь _оптимизация_ трафика. C>Надо ещё умножить на вероятность появления ошибки в пакете. Она меньше 10^-9.
Это на очень хороших каналах (типа правильно уложенной оптики при некитайских конвертерах, правильном электропитании, etc.)
На модемных линках ранее и 10^-4 было хорошим результатом.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Pepel, Вы писали:
MSV>>>>>Решил создать новый протокол на основе udp. P>>>>неудачный выбор, при высокой утилизации сетки udp шные пакеты отбрасываются тучами, N>>>UDP или вообще IP? Что-то я не замечал в алгоритмах контроля трафика какого-то особого предпочтения UDP. P>>значит плохо наблюдали, udp пакеты при загрузки сети прост херятся без зазрения совести
N>Вы явно не читаете того, что Вам пишут. N>У средств ограничения трафика нет никакого предпочтения UDP. Херятся все одинаково. N>А если Вы применяете UDP на управляющем или наливном трафике без контроля доставки — это исключительно Ваша ошибка.
ошибок у меня нет, у меня все в порядке, ошибка (генетическая) по-моему мнению, у того, кто пытается на основе udp мастерить свою приебошку аля tcp
MSV>В текущей реализации я постарался оптимизировать передаваемую информацию. Не знаю, получится ли создать хороший протокол и одновременно оптимизировать трафик. Похоже пора вспоминать, как делаются чудеса. ^_^
Ну при должном рвении через недельку-другую у тебя будет чета работающее а через месяц-другой ты поймешь всю бредовость идеи
Но зато поймешь лучше как работает TCP
Как много веселых ребят, и все делают велосипед...
Здравствуйте, MikelSV, Вы писали:
MSV>Понял, что не понял, как слать udp пакеты, при желании ими легко забьется канал и придется пересылать пакеты заново. MSV>Полагаю будет установлено максимальное количество пакетов в "пути".
На венде надо ставить через setsockopt() параметр SO_RCVBUF во что-нибудь вменяемое. Он там по дефолту всего 16 К и мгновенно забивается, стоит вашей программе ненадолго потерять управление.
MSV>К удивлению обнаружил, что udp пакеты больше 1кб не доходят на локальном компьютере. MSV>Чем меньше пакет, тем больший объем служебных данных получается.
У меня пакеты размером чуть меньше 1.5К без проблем ходят по всему Интернету, и не пролазят только там, где вообще никакой UDP не пролазит. Ищите ошибку в своем коде.
Pzz>У меня пакеты размером чуть меньше 1.5К без проблем ходят по всему Интернету, и не пролазят только там, где вообще никакой UDP не пролазит. Ищите ошибку в своем коде.
Это у вас. Вам везет
А вообще TCP автоматически определяет размер MTU, например вот так: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q136970
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
MSV>>В текущей реализации я постарался оптимизировать передаваемую информацию. Не знаю, получится ли создать хороший протокол и одновременно оптимизировать трафик. Похоже пора вспоминать, как делаются чудеса. ^_^ O>Ну при должном рвении через недельку-другую у тебя будет чета работающее а через месяц-другой ты поймешь всю бредовость идеи O>Но зато поймешь лучше как работает TCP
Ну почему ж бредовость. я с tcp в равных условиях. хотя, шапка у tcp 20 байт, а у udp всего 8. у меня 12байт преимущества ^_^.
Пакеты именно не слались. Доходил один пакет с кодом начала соединения, а второй уже терялся.
Опытным путем установил, что пакеты ^W я идиот. Читал по 1к. ^_^ пакеты доходят.
Кажется 1536айт стандартный размер, который должен проходить везде.
Осталось отладить контроллер пакетов и оптимизировать алгоритмы управления пакетами.
Немного мучает вопрос, куда складывать приходящие данные. Ждать, пока их запросят или активно пихать в функцию или класс.
Также предстоит нормальная организация буфера приема и передачи. подозреваю придется достаточно много думать в этой задачке. Просто new не правильный вариант. На мой взгляд нужен заранее выделенный буфер.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
MSV>Ну почему ж бредовость. я с tcp в равных условиях. хотя, шапка у tcp 20 байт, а у udp всего 8. у меня 12байт преимущества ^_^.
не в шапке дело
MSV>Пакеты именно не слались. Доходил один пакет с кодом начала соединения, а второй уже терялся. MSV>Опытным путем установил, что пакеты ^W я идиот. Читал по 1к. ^_^ пакеты доходят. MSV>Кажется 1536айт стандартный размер, который должен проходить везде.
Eсли кажется — надо читать стандарты. В данном случае имеет место "обычно проходит почти везде"
MSV>Осталось отладить контроллер пакетов и оптимизировать алгоритмы управления пакетами. MSV>Немного мучает вопрос, куда складывать приходящие данные. Ждать, пока их запросят или активно пихать в функцию или класс.
TCP ложит в буфер. Когда буфер кончается — ack'ами говорит другой стороне что я жив, но пока больше слать ниче не надо. Другая сторона больше и не шлет.
MSV>Также предстоит нормальная организация буфера приема и передачи. подозреваю придется достаточно много думать в этой задачке. Просто new не правильный вариант. На мой взгляд нужен заранее выделенный буфер.
Проблема с буферами — самая малая часть проблем из всех.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, MikelSV, Вы писали:
MSV>Ну почему ж бредовость. я с tcp в равных условиях. хотя, шапка у tcp 20 байт, а у udp всего 8. у меня 12байт преимущества ^_^.
У TCP шапка, вообще-то, маловата. Ладно 16 бит на порт (не всегда достаточно, но расширять — отдельный кусок гемора), но 32-битные позиции — на сейчас крайне мало, а для 64-битных добавляй ещё 8 байт. Но в своём протоколе придётся, если ориентироваться на разноразмерные пакеты, делать то же самое, если не хуже.
MSV>Опытным путем установил, что пакеты ^W я идиот. Читал по 1к. ^_^ пакеты доходят. MSV>Кажется 1536айт стандартный размер, который должен проходить везде.
Нет такой цифры в этом слове.
1500 — предельный размер внутренностей пакета, который гарантирован для прохождения через все варианты реализации Ethernet без дополнительных наворотов. Причём это при общепринятой (но не стандартной с точки зрения ISO!) EthernetII инкапсуляции. Если же, как рекомендуют по-европейски, 802.2+SAP+SNAP — остаётся 1492.
Дальше эта цифра может как увеличиваться (jumbo frames), так и уменьшаться (туннели и VPN'ы всех видов). Но Ethernet — мягко говоря, не единственный теоретически возможный тип линка.
Минимальный MTU для IPv4 многих наверняка шокирует — он равен 68 (прописью: шестьдесят восемь) октетов. Это сказано английским по фоновому в STD0001 (RFC0791). Разные рекомендации поднимают этот уровень выше (SLIP — 296, PPP — 552, RFC1122 — 576), но максимум что есть из рекомендаций — "старайтесь делать его не менее 576" (RFC1122 пункт 3.3.3).
Для IPv6 минимальный MTU — 1280. Это уже хоть как-то похоже на современные практически известные цифры.
Практика очень размыта, но в среднем сводится примерно к "старайтесь не передавать более 1200-1400 за раз". Например, в RFC3261 (SIP) жёстко сказано "более 1300? => идите на TCP и не выделывайтесь".
Здравствуйте, fk0, Вы писали:
N>>то у меня получается в самом коротком случае 3 байта испорченных, иногда 4, обычно же оно не находит случаев короче чем 8 байт. Для CRC-8 это очень хороший результат. А твой пример умудряется находить даже последовательности с изменением одного последнего байта, что заведомо показывает на ошибочность твоего кода (собственно почему я и стал рыть). fk0> Исправил. Так ведь получается. Вот пример для 1000 запусков:
Ничего неожиданного. Естественно, можно подобрать такие данные, что на них с подобной стандартной заменой получится "немного" не то, но с той же суммой.
Но для таких ситуаций надо вообще что-то принципиально другое придумывать, чем суммы. Я взял твой код и попытался сделать следующие варианты замен:
1) вместо CRC — младшие 8 бит суммы байт
2) то же но с переносом старшего бита в конец (не XOR, а добавлением) (в стиле IP?)
Результат удручает — ни одна сумма такой ситуации не ловит. Статистически лучше всего, похоже, просто младший байт суммы всех байт потока, но тоже качество обнаружения отвратительное.
Так что я бы тут не ругался на авторов идеи применить CRC. Чтобы ловить подобный клин приёмника или чужое вмешательство, нужно просто другое построение протокола. Например, фиксированный последний байт ответа, в котором и нули и единицы (типа 0x5a).
fk0> Это CRC с указанным полиномом и его результат для любых входных значений полностью совпадает с побитным алгоритмом CRC. Указанный полином на сайте smbus.org... Указанные коэффициенты для ксорки берутся из результатов вычисления таблицы CRC побитным алгоритмом и взятия каждого 2^N-го члена для N=0..7. Это оптимизированный алгоритм просто. И, кстати, на мелких контроллерах он может работать быстрее табличного (на гарвардских архитектурах доступ к данным в программной памяти -- медленный).
Я не про способ вычисления — понятно, что он подбирается под реализацию. А про собственно алгоритм. Впрочем, я уже нашёл как его логически описать: он эквивалентен классическому, но с добавлением ещё одного нулевого байта в конце входной последовательности.
fk0> Увы и ах. Именно так, именно для того он и предназначен. И в RS-232 будет замечательно работать. А где пакетная передача с обрывами посереди пакета и заполнением конца пакета одинаковым битом -- не канает CRC.
Как уже сказал — там никакая сумма "не канает" пока нет подтверждения собственно целостности канала.
fk0> Ничего подобного. Ситуация там такая: приём данных мастером, слейв отвалился по электрическим причинам (стоп-сигнал увидел и т.п.) На шине соответственно единица (обеспечивается резистором подтяжки) всё время. А мастер так уверенно читает все биты до конца пакета и *никак* не может знать, что слейв уже обмен закончил. Между байтами разделения в I2C нет, как и границ байтов в данном случае. В случае когда мастер записывал бы -- да, разделение есть, слейв должен на каждый байт ACKnowledge нулевым битом давать. А тут мастер должен ACK давать -- ну вот он и даёт, и читает дальше... Это в значительной степени проблема шины и протокола SMBUS (обязательный нулевой бит в конце пакета кардинально решал бы проблему).
Вот именно, что шины.
fk0> Кстати ещё пример неправильного применения CRC -- контрольный код записи в FLASH-памяти. Догадываешься уже почему? Ровно та же проблема. Массовое FF-чивание отдельных блоков. Контрольная сумма подходящей разрядности (весьма небольшой) опять же справляется гарантировано и это очевидно математически.
Нет. Модифицируй свою программу и проверь: точно так же не справляется.
Здравствуйте, netch80, Вы писали:
N>>>то у меня получается в самом коротком случае 3 байта испорченных, иногда 4, обычно же оно не находит случаев короче чем 8 байт. Для CRC-8 это очень хороший результат. А твой пример умудряется находить даже последовательности с изменением одного последнего байта, что заведомо показывает на ошибочность твоего кода (собственно почему я и стал рыть). fk0>> Исправил. Так ведь получается. Вот пример для 1000 запусков: N>Ничего неожиданного. Естественно, можно подобрать такие данные, что на них с подобной стандартной заменой получится "немного" не то, но с той же суммой. N>Но для таких ситуаций надо вообще что-то принципиально другое придумывать, чем суммы. Я взял твой код и попытался сделать следующие варианты замен: N>1) вместо CRC — младшие 8 бит суммы байт N>2) то же но с переносом старшего бита в конец (не XOR, а добавлением) (в стиле IP?)
N>Результат удручает — ни одна сумма такой ситуации не ловит. Статистически лучше всего, похоже, просто младший байт суммы всех байт потока, но тоже качество обнаружения отвратительное.
16-битная сумма в 256-байтном пакете (и более коротких) гарантированно ловит такие ситуации. Вроде ж очевидно. 16-битный CRC тоже их ловить не будет, хотя и с меньшей вероятностью.
fk0>> Это CRC с указанным полиномом и его результат для любых входных значений полностью совпадает с побитным алгоритмом CRC. Указанный полином на сайте smbus.org... Указанные коэффициенты для ксорки берутся из результатов вычисления таблицы CRC побитным алгоритмом и взятия каждого 2^N-го члена для N=0..7. Это оптимизированный алгоритм просто. И, кстати, на мелких контроллерах он может работать быстрее табличного (на гарвардских архитектурах доступ к данным в программной памяти -- медленный). N>Я не про способ вычисления — понятно, что он подбирается под реализацию. А про собственно алгоритм. Впрочем, я уже нашёл как его логически описать: он эквивалентен классическому, но с добавлением ещё одного нулевого байта в конце входной последовательности.
Да он полностью эквиэвалентен. Я ж написал -- я налажал в коде. И написал как исправить.
fk0>> Увы и ах. Именно так, именно для того он и предназначен. И в RS-232 будет замечательно работать. А где пакетная передача с обрывами посереди пакета и заполнением конца пакета одинаковым битом -- не канает CRC. N>Как уже сказал — там никакая сумма "не канает" пока нет подтверждения собственно целостности канала.
Когда в канале не произвольные искажения, а исключительно об 00-вание или об FF-чивание, то сумма соответствующей разрядности просто гарантирует.
fk0>> Кстати ещё пример неправильного применения CRC -- контрольный код записи в FLASH-памяти. Догадываешься уже почему? Ровно та же проблема. Массовое FF-чивание отдельных блоков. Контрольная сумма подходящей разрядности (весьма небольшой) опять же справляется гарантировано и это очевидно математически. N>Нет. Модифицируй свою программу и проверь: точно так же не справляется.
Это ж очевидно, что если в последовательности единиц и нулей часть последовательности заменить на единицы или нули, то сумма станет соответственно такой же или большей, или такой же (когда 0 заменяется на 0) или меньшей. Для одного разряда это так (проверь). И для каждого N+1 тоже (доказано). Если в сумме нет переполнений -- поэтому разрядность должна быть больше, чем log2(sum(все единицы)).
Здравствуйте, fk0, Вы писали:
N>>Результат удручает — ни одна сумма такой ситуации не ловит. Статистически лучше всего, похоже, просто младший байт суммы всех байт потока, но тоже качество обнаружения отвратительное. fk0> 16-битная сумма в 256-байтном пакете (и более коротких) гарантированно ловит такие ситуации. Вроде ж очевидно.
Ах, 16-битная при байтах... ну это уже приём за гранью допустимого. До сих пор контекстом были или IP пакеты (тогда и 16-битная не справится, надо 32), или SMBus (тогда шла речь про 8-битные). А если у тебя будут передачи длиннее 256 байт — что делать, до 32 расширять? Боюсь, обидятся на оверхед.
fk0>>> Кстати ещё пример неправильного применения CRC -- контрольный код записи в FLASH-памяти. Догадываешься уже почему? Ровно та же проблема. Массовое FF-чивание отдельных блоков. Контрольная сумма подходящей разрядности (весьма небольшой) опять же справляется гарантировано и это очевидно математически. N>>Нет. Модифицируй свою программу и проверь: точно так же не справляется.
fk0> Это ж очевидно, что если в последовательности единиц и нулей часть последовательности заменить на единицы или нули, то сумма станет соответственно такой же или большей, или такой же (когда 0 заменяется на 0) или меньшей. Для одного разряда это так (проверь). И для каждого N+1 тоже (доказано). Если в сумме нет переполнений -- поэтому разрядность должна быть больше, чем log2(sum(все единицы)).
И опять-таки у тебя должна быть очень большая контрольная сумма. Например, при записи порциями по 32 бита (чтобы было достаточно эффективно) в ней должно быть 40-48 бит. К тому же добавляется проблема проверки суммированием... боюсь, на сейчас выгоднее другие примеры применить. Например, RC при тех же недостатках с необходимостью последовательной обработки умеет корректировать данные, что явно важнее.
В общем, твой подход показателен как крайний вариант, но слабоприменим на практике — его можно сравнить с шифрованием с помощью шифроблокнота: надёжность абсолютная, но сопроводительного геморроя слишком много.
Как говорится: "для нас чужие проблемы только в радость."
Что сказать, неправильно сделали.
Протокол доделал. гоняет, правда медленно. работаю над менеджером пакетов. стараюсь учесть опыт tcp.
Основная же проблема в куче вариантов реализаций. Но в принципе, все логически просчитывается и достаточно легко создается простой вариант tcp.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, LuciferSaratov, Вы писали:
LS>Эх, твою бы энергию да в мирных целях.
А вы еще не заметили, что цели мирные?
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
