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

Осознал, что написанный код устарел и выкинул его нафик. Пишу заново. Кстати, вполне успешно.
Удалось передать файл, пока на локальном компьютере.
Есть и контроллер пакетов, ошибки к сожалению пока не исправляет, но это дело времени.

Не совсем понял все рассуждения насчет crc. Нужен ли дополнительный контроль данных в пакете?

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

К удивлению обнаружил, что udp пакеты больше 1кб не доходят на локальном компьютере.
Чем меньше пакет, тем больший объем служебных данных получается.

В текущей реализации я постарался оптимизировать передаваемую информацию. Не знаю, получится ли создать хороший протокол и одновременно оптимизировать трафик. Похоже пора вспоминать, как делаются чудеса. ^_^

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 и не выделывайтесь".