Это нормально что UDP пакет недоходят?

Сперва надо узнать, что не долетело. То есть сочинять свой протокол подтверждения доставки.

и что там сложного?

В UDP её нет — сохранять нечего, dixi. Ты можешь создать заново, сочинить прикладной протокол. Написать урезанный аналог TCP. Только я сильно сомневаюсь, что твой велосипед будет хоть сколь-нибудь лучше TCP. Скорее всего только хуже.

почему это? Если я понимаю, что меня не устраивает в TCP, то что мне помешает это изменить? TCP очень простой протокол, а менять я его не могу не из-за сложностей, а просто потому, что это общепринятый стандарт. Ну вот ту же глупую сумму в 16 бит из 60х годов прошлого века я НЕ поменяю. Стандарт. Режект на первом же роутере.

Если думаешь, TCP все эти годы стоял на месте, — сильно ошибаешься. Кажется, SACK сейчас уже все понимают, например.

о да. Это конечно сильное улучшение.

теперь будешь доказывать, что уровень ниже как-то всё страхует и что-то там гарантирует?

А кто говорит о гарантиях? Речь лишь о вероятностях.

скачай любой образ по голому TCP, тот же Linux*.iso на 4Г. Часто половина боя получается

Выкинь свое железо. Ни разу в жизни не скачал ни одного битого файла с ftp://ftp.freebsd.org. Практика, которая критерий истины, такова: у меня есть несколько магистральных линков, только на одном были зафиксированы ошибки CRC, но там некоторое время наблюдались проблемы с регенерацией на DWDM, даже FEC не помогала.

На остальных нет ни одной проблемы. Какова вероятность возникновения на канале уникального набора случайных ошибок передачи, который привел бы к коллизии CRC32, но при этом ни до ни после не было бы ни одной ошибки?

считаешь проверку TCP абсолютной.

Где это ты вычитал? Проверка 16-бит контрольной суммой слаба.

Очевидно - мало кто это поле использует, ибо тормозит и дорого.

Очевидно, у тебя тупая сетевуха, которая не проверяет CRC32 хотя бы в драйвере. Такие есть, да.

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

Пакеты-то бьются, факт.

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

и что там сложного?

Передал пакет, подождал подтверждения, передал следующий? «Подождал» — это и 100–200, и временами 300 мс.

Если я понимаю, что меня не устраивает в TCP, то что мне помешает это изменить?

Я совсем не уверен, что твои изменения пойдут ему на пользу :)

о да. Это конечно сильное улучшение.

Да, сильное. Если ты не понимаешь, как SACK улучшило работу именно на современных каналах, то тебе рано изобретать конкурента TCP.

Выкинь свое железо. Ни разу в жизни не скачал ни одного битого файла с ftp://ftp.freebsd.org.

тут не в железе дело, а скорее в говнопровайдерах. Которых у нас в Питере 95%.

Практика, которая критерий истины, такова: у меня есть несколько магистральных линков, только на одном были зафиксированы ошибки CRC, но там некоторое время наблюдались проблемы с регенерацией на DWDM, даже FEC не помогала.

ну и я о чём. А вот конкретно в ДС2 последняя миля реализована так, что образы даже в 700Мб можно качать только торрентом или проверять md5 и часто перекачивать. Ибо не сходится. И я не думаю, что тут виноват браузер или wget, или ещё что-то верхнего уровня.

Народ пишет, что в ДС1 и в регионах всё не лучше (а в регионах ессно хуже).

На остальных нет ни одной проблемы. Какова вероятность возникновения на канале уникального набора случайных ошибок передачи, который привел бы к коллизии CRC32,

намного меньше 1/4294967296, ибо большинство ошибок передачи CRC32 вылавливает, ибо на то и заточена.

Где это ты вычитал? Проверка 16-бит контрольной суммой слаба.

ага. А в TCP это единственный механизм проверки.

Очевидно, у тебя тупая сетевуха, которая не проверяет CRC32 хотя бы в драйвере. Такие есть, да.

причём тут _моя_ сетевуха? И кстати, у меня их штук 5 в работе, на моих локалхостах. Я не по ним сужу.

Знаешь, я уже вообще не припомню, когда в последний раз видел отличное от нуля количество ошибок CRC в локальной сети.

мы про глобальную. В локалке и у меня вроде без ошибок (не наблюдал, да).

Передал пакет, подождал подтверждения, передал следующий? «Подождал» — это и 100–200, и временами 300 мс.

зачем же так тупо делать? передаёшь и принимаешь. Складываешь принятые в буфер. Отдаёшь готовое. Ждёшь _только_ если нет нужного пакета, и если его не присылают повторно.

Я совсем не уверен, что твои изменения пойдут ему на пользу :)

откуда такая неуверенность? TCP открыт, и отлично документирован. Единственная беда - настраивать его можно только _глобально_. Сам он конечно тоже умеет настраиваться, но этого не всегда хватает. Ну например при передачи большого файла по не самому лучшему каналу, TCP начинает дробить пакеты, с одной стороны это конечно хорошо, но таки увеличивает вероятность ошибки. Глобально это не поправить, ибо для мелких файлов это хорошо работает, и не нужно это портить, но локальных настроек(для какого-то отдельного соединения) таких нет.

Да, сильное. Если ты не понимаешь, как SACK улучшило работу именно на современных каналах, то тебе рано изобретать конкурента TCP.

я понимаю. Только твоему SACK тоже уже лет 15 минимум. Видишь, с какой скоростью приходят твои улучшения? А в своём протоколе ты можешь хоть каждый день менять что угодно.

Ну например при передачи большого файла по не самому лучшему каналу, TCP начинает дробить пакеты, с одной стороны это конечно хорошо, но таки увеличивает вероятность ошибки

Мне кажется дальше спорить смысла нет.

В конфиге OpenVPN mss=512 поставь. TCP требует MTU 576 (хотя раньше попадалиьс и сети с mtu около 200, ха). На нестабильных сетях будет двойной TCP, тоже спорно.

Ну например при передачи большого файла по не самому лучшему каналу, TCP начинает дробить пакеты, с одной стороны это конечно хорошо, но таки увеличивает вероятность ошибки.

Хмм... «Помолчи — за умного сойдёшь», «иногда лучше жевать, чем говорить», «прочтите, наконец, документацию (и что-то по терверу)»

образы даже в 700Мб можно качать только торрентом или проверять md5

Я вижу единственную возможность такого поведения: большие проблемы на доступе, а твоё канальное оборудование не проверяет CRC32. Проблемы с RAM мы пока отбрасываем. Покажи счетчики на стыке с провайдером.

мы про глобальную.

А глобальная — это такая сеть локалок. Сеть сетей, да. Ещё раз, у меня на магистральных стыках протяженностью в сотни километров нет ошибок crc. А когда вдруг возникают — это повод заставить заменить проблемное железо и поиметь денег или дополнительную полосу.

Понимаешь, любой самый захудалый store-n-forward коммутатор проверяет crc32 и отбрасывает битые пакеты. То есть сеть доступа твоего провайдера — это вполне себе такая «локалка». На чём она построена хоть?

намного меньше 1/4294967296, ибо большинство ошибок передачи CRC32 вылавливает, ибо на то и заточена.

Именно, причем существенно меньше, и зависит от BER. Смотри, когда два набора данных дают одинаковый хеш или crc — это коллизия. Но чтобы воспользоваться коллизией, одного знания 2^(длина_хеша) недостаточно. Проблема не в том, что два блока могут дать один хеш, а в том, чтобы найти этот второй.

Точно также, когда два изернет кадра дают одинаковую crc — это в подавляющем большинстве случаев не проблема. Вероятность только лишь с помощью случайных битовых ошибок в канале передачи получить из букв Ж, О, П и А слово «счастье» будет незначительна.

Я вижу единственную возможность такого поведения: большие проблемы на доступе, а твоё канальное оборудование не проверяет CRC32.

обязательно моё?

Проблемы с RAM мы пока отбрасываем. Покажи счетчики на стыке с провайдером.

вот на этом я не проверял. сейчас ADSL только под рукой, там вроде своя CRC есть. А с гнилой рам и торрент не поможет.

А глобальная — это такая сеть локалок. Сеть сетей, да. Ещё раз, у меня на магистральных стыках протяженностью в сотни километров нет ошибок crc. А когда вдруг возникают — это повод заставить заменить проблемное железо и поиметь денег или дополнительную полосу.

ну ты - хороший админ. Все тоже так делают?

Понимаешь, любой самый захудалый store-n-forward коммутатор проверяет crc32 и отбрасывает битые пакеты. То есть сеть доступа твоего провайдера — это вполне себе такая «локалка». На чём она построена хоть?

понимаю. сейчас под рукой такого отстоя нет. Скажи, проверка CRC32 обязательна? Её отключить нельзя?

Именно, причем существенно меньше, и зависит от BER.

я в курсе, но это никак не относится к проверке в TCP.

Ждёшь _только_ если нет нужного пакета, и если его не присылают повторно.

Здесь с приемной стороной всё более или менее понятно. Как у тебя передающий узнает, что пакет принят, и его можно уже не хранить для повторной передачи? У тебя положительное или отрицательное подтверждение доставки? Как передающий узнает, что всё переданное с определенного момента ушло в дроп по дороге, и пора бы перестать гнать коней и снизить скорость?

Это лишь самые первые и простые вопросы.

откуда такая неуверенность? TCP открыт, и отлично документирован.

Именно поэтому.

TCP начинает дробить пакеты, с одной стороны это конечно хорошо, но таки увеличивает вероятность ошибки.

Ты уже понял, где ошибся?

Видишь, с какой скоростью приходят твои улучшения?

Не надо чинить работающее.

Это лишь самые первые и простые вопросы.

странные вопросы: я говорил о том, что поверх UDP можно реализовать _другой_ протокол, для _других_ условий. Ты спрашиваешь «какой конкретно?». Ну откуда я знаю? Не устраивает подтверждение? Сделай другое. Устраивает всё в TCP? тогда какой смысл? Ты уже пытаешься найти изъяны в моей реализации, а я даже не знаю, на кой хрен она вообще мне сдалась?

TCP начинает дробить пакеты, с одной стороны это конечно хорошо, но таки увеличивает вероятность ошибки.

Ты уже понял, где ошибся?

нет ещё. Мы пока ещё не определились с тем, что я понимаю под словом «ошибка». Ты ещё разве не понял? Ну тогда см. выше. Это такой неправильный пакет, который принят TCP протоколом как годный.

Не надо чинить работающее.

не надо. Если-бы оно всегда и везде работало-бы. Часто оно тупо не нужно. А если и нужно, то может и не оно.

обязательно моё?

Но ведь это ты принимаешь битые пакеты, когда 16-бит дополнение не выручает. Если бы твоя канальная железка проверяла crc32, то почти наверняка был бы просто большой процент потерь, но никак не ошибок в прикладных данных.

сейчас ADSL только под рукой, там вроде своя CRC есть.

Ну так посмотри на модеме BER, SNR, CRC-errors, Re-syncs, чего ещё там есть…

Все тоже так делают?

Ну естественно. Бабки-то уплачены. Если ты арендуешь L2VPN из Москвы в Нижний Новгород или лямбду из Екатеринбурга в Новосибирск, а там дропы и флапы, то конечно же скушаешь продавцу все мозги, и технарям, и комерсам. Ведь если не ты, то твои клиенты тебе.

Скажи, проверка CRC32 обязательна? Её отключить нельзя?

По стандарту обязательна, отключить обычно нельзя. Кроме сверхдешевых CPE железок, которые проверяют в софте — там могут «наоптимизировать» производительность, разгрузив процессор от «лишней» работы.

я в курсе, но это никак не относится к проверке в TCP.

До проверки в TCP дойдет только после получения ошибочного изернет фрейма с верной crc32. Ты ведь уже представляешь себе порядок чисел, на сколько отброшенных пакетов с кривой crc может придти один с верной. То есть какие числа должен показывать счетчик ошибок, и какие потери должны быть в канале, чтобы это случилось за разумное время.

Ты уже понял, где ошибся?

нет ещё.

Ты ошибся с вероятностью. Если дойдет, почему, можем продолжить разговор.

я говорил о том, что поверх UDP можно реализовать _другой_ протокол, для _других_ условий.

Можно и штаны через голову надевать…

Ну откуда я знаю?

То есть ты не знаешь, чего может не хватать в TCP, и не понимаешь, как реализовать аналогичный протокол. Хотя тебе ведь понадобился протокол для «передачи гигасов варезов по несимметричным говнолинкам с ненормированными дропами».

неправильный пакет, который принят TCP протоколом как годный

Может для тебя будет шоком, но IP считает достаточным обнаружение ошибок на канальном уровне, поэтому из IPv6 расчет контрольной суммы заголовка вообще убрали.

Контрольная сумма в TCP нужна только как дополнительная end-to-end проверка на тот редчайший случай, когда не справились ни физический, ни канальный уровни на каком-нибудь промежуточном этапе передачи.

Если-бы оно всегда и везде работало-бы.

Давай примеры, и будем обсуждать.

Но ведь это ты принимаешь битые пакеты, когда 16-бит дополнение не выручает. Если бы твоя канальная железка проверяла crc32, то почти наверняка был бы просто большой процент потерь, но никак не ошибок в прикладных данных.

давай я тебе передам Over9000 мусорных пакетов с верной CRC32? С чего ты взял, что ВСЕ маршрутизаторы аккуратно проверяют пакеты, и отбрасывают битые? С моими железками всё нормально: как я уже говорил, в локалке у меня такого не было, нет, и очевидно не будет. А вот в глобальной сети - было.

Ну естественно. Бабки-то уплачены. Если ты арендуешь L2VPN из Москвы в Нижний Новгород или лямбду из Екатеринбурга в Новосибирск, а там дропы и флапы, то конечно же скушаешь продавцу все мозги, и технарям, и комерсам. Ведь если не ты, то твои клиенты тебе.

это если у тебя 50% пакетов битых. А если 1%? Как клиент это заметит? А если даже заметит, и зафиксирует «BER, SNR, CRC-errors, Re-syncs, чего ещё там есть…», то кто его слушать будет? «проблемы на вашей стороне». Послушай, что ТЫ мне сейчас говоришь - ты же на меня УЖЕ стрелки переводишь, и готов отстаивать все транзитные узлы, дескать с ними всё в порядке, а проблема у тебя. Дык ты сейчас не с обиженным хомячком разговариваешь, я по этому поводу даже и обращаться не буду, просто тупо сменю провайдера, благо ISP сейчас как грязи.

По стандарту обязательна, отключить обычно нельзя.

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

До проверки в TCP дойдет только после получения ошибочного изернет фрейма с верной crc32. Ты ведь уже представляешь себе порядок чисел, на сколько отброшенных пакетов с кривой crc может придти один с верной. То есть какие числа должен показывать счетчик ошибок, и какие потери должны быть в канале, чтобы это случилось за разумное время.

я это давно представляю. Ничего нового ты мне не открыл, даже твой перевод стрелок, дескать «проблема на вашей стороне», тоже вполне типичен, и не нов.

Ещё раз повторяю: я не знаю, откуда берутся битые пакеты TCP, но они есть, это факт.

Ты ошибся с вероятностью. Если дойдет, почему, можем продолжить разговор.

ну и где я ошибся?

Дано: приходит битый TCP пакет.
Найти: вероятность того, что этот битый TCP пакет будет признан годным.

Разве ты не понимаешь, что если пакет побьётся на канальном уровне, то до TCP он тупо не дойдёт? Ну не будет такого пакета, и всё.

То есть ты не знаешь, чего может не хватать в TCP

я знаю, чего _может_ не хватать в TCP.

Может для тебя будет шоком, но IP считает достаточным обнаружение ошибок на канальном уровне, поэтому из IPv6 расчет контрольной суммы заголовка вообще убрали.

неа. Не будет. Вот например это _можно_ и убрать, ибо толку от этой проверки всё равно никакого нет, о чём я тебе и говорил. Однако ты же считаешь свой TCP идеалом, и считаешь, что его контрольная сумма очень нужна и востребованная? Или нет? Определись.

Контрольная сумма в TCP нужна только как дополнительная end-to-end проверка на тот редчайший случай, когда не справились ни физический, ни канальный уровни на каком-нибудь промежуточном этапе передачи.

бред полный. Почему в свою маршрутку ты не поставил пятое колесо, на случай end-to-end?

Контрольная сумма в TCP нужна только как дополнительная end-to-end проверка на тот редчайший случай, когда не справились ни физический, ни канальный уровни на каком-нибудь промежуточном этапе передачи.

Давай примеры, и будем обсуждать.

я уже давал: хомячок качает файл в 4Гб, и получает неверную md5. У него нормальная сетевая карта. ЧОДНТ?

Вот именно такие велосипедисты и изобретают µTP, в одночасье в разы увеличивая PPS без всякой уважительной причины.

совсем нет причин?
http://www.bittorrent.org/beps/bep_0029.html

ВСЕ маршрутизаторы аккуратно проверяют пакеты, и отбрасывают битые?

Все, с которыми приходилось сталкиваться. И не только маршрутизаторы, все store-and-forward коммутаторы отбрасывают пакеты с кривой FCS, то есть подавляющее большинство. Хотя я допускаю лихо настроенный линукс-сервер, терминирующий PPPoE у лохопровайдера. Ну так ССЗБ.

я уже говорил, в локалке у меня такого не было

Как вариант, в локалке у тебя коммутатор битые пакеты дропает, а интерфейс к провайдеру — нет. Кривое CPE и дерьмовый доступ вполне могут иметь место. А вот на магистралях пролезающие за пределы FEC ошибки обычно сразу вызывают интенсивный обмен любезностями между сторонами.

А если 1%? Как клиент это заметит?

По дропам, например. Да никто и не будет ждать жалоб клиента, если происходит деградация трафика.

просто тупо сменю провайдера, благо ISP сейчас как грязи

Вот именно поэтому все нормально сотрудничают: аплинк тоже прекрасно понимает, что завтра я уйду к конкуренту, если он не пошевелится и не ликвидирует полочку на своем линке с Телией.

Послушай, что ТЫ мне сейчас говоришь - ты же на меня УЖЕ стрелки переводишь

Во-первых, человек, заявляющий «у меня что-то неправильно работает, но логи и счетчики ошибок я не покажу, — они провайдер, сами пусть и разбираются», обычно идет лесом. К нему приносят какой-нибудь Fluke, показывают красивые буковки о соответствии абонентской линии стандартам, и тактично посылают «чинить свои customer-premises глюки». И вешают флажок «склочник, тактично игнорировать».

я не знаю, откуда берутся битые пакеты TCP, но они есть, это факт

Лет пятнадцать назад проводилось исследование, откуда в интернете берутся битые TCP пакеты (с неправильной контрольной суммой). Оказалось, большинство приходит с правильной CRC32, и не детектируется на канальном уровне, а ошибки вносятся передающий стороной после формирования TCP пакета или принимающей перед проверкой контрольной суммы из-за сбоев ОЗУ, багов в реализации IP стека, драйвера и так далее, порядка сотни патернов ошибок.

Тогда же оценили вероятность получения битого TCP пакета с верной суммой, ЕМНИП что-то около одного на десяток терабайт данных при условии получения более одного неверного TCP пакета на каждые 32к полученных.

С тех пор IP стеки сильно исправились, а память на серверах и маршрутизаторах почти всегда ECC.

я знаю, чего _может_ не хватать в TCP.

Чего?

Однако ты же считаешь свой TCP идеалом

Слушай, прости конечно за вопрос, но у тебя глаза черно-белые или мозги? TCP good enough, и нет смысла от него отказываться без веских на то оснований.

бред полный.

Это тебе от незнания так кажется. FCS в изернете защищает фрейм только при передаче точка-точка между сетевухами. Для передачи по следующему участку сети CRC32 (или ещё что получше) будет подсчитана заново. А вот контрольная сумма TCP пакета создана отправителем, идет прозрачно, и проверяется получателем. Ну как, end-to-end проверка уже не бред?

хомячок качает файл в 4Гб, и получает неверную md5

Я сегодня зашел на старый компьютер сына, написал скриптик, который десять раз подряд сделал

wget ftp://ftp.ru.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/9.1/\*

> sysctl dev.nfe.0.stats.rx
dev.nfe.0.stats.rx.frame_errors: 0
dev.nfe.0.stats.rx.extra_bytes: 0
dev.nfe.0.stats.rx.late_cols: 0
dev.nfe.0.stats.rx.runts: 0
dev.nfe.0.stats.rx.jumbos: 0
dev.nfe.0.stats.rx.fifo_overuns: 0
dev.nfe.0.stats.rx.crc_errors: 0
dev.nfe.0.stats.rx.fae: 0
dev.nfe.0.stats.rx.len_errors: 0
dev.nfe.0.stats.rx.unicast: 1225346196
dev.nfe.0.stats.rx.multicast: 23960687
dev.nfe.0.stats.rx.broadcast: 8297393
dev.nfe.0.stats.rx.octets: 386888328079
dev.nfe.0.stats.rx.pause: 0
dev.nfe.0.stats.rx.drops: 0

Что и откуда надо скачать, чтобы увидеть битый файл?

совсем нет причин?

Я прекрасно знаю, чем они объясняют: не мешать интерактивному трафику на дерьмовом несколько-килобитном аплинке тормозного ADSL.

Вот только внедрение протокола с оверхедом более 50% вместо улучшений вызвало массовые отказы тех самых дерьмовых ADSL и WiFi-роутеров стремительным домкратом.

Когда они говорят, «полный 1500 байт пакет будет передаваться целых 200 миллисекунд, и на это время приостановится интерактивный трафик загрузки веб-страницы, поэтому надо передавать только мелкими пакетами», я спрашиваю, «с каких пор восемь килобит в секунду — современные каналы, на которые надо ориентироваться?»

В результате сделали так, что уменьшение размера пакета влечет рост pps, который влечет ухудшение качества канала, которое влечет уменьшение размера пакета, которое… Ну и далее вплоть до 150 байт.

Получили протокол, отключение которого улучшает ситуацию.

<ссылка на bep-29>

Вот только они сперва втихаря написали уродский протокол, затем так же молча его подсунули хомячкам, вызвав двух–трех кратный рост pps в интернете и кучу воя на вешающиеся маршрутизаторы и проблем мелким провайдерам с софтроутерами. А потом выкатили bep. Причем реализация и самого µTP и LEDBAT отличается от описанной в bep и ietf драфте.

Потом ещё полгода отбрыкивались, не признавая косяков.

А ведь могли бы просто написать LEDBAT как CC для TCP, все современные ОС поддерживают. Но тогда не надо было бы изобретать велосипед, неспортивно.

хм, насчет µTP почитаю еще

А ведь могли бы просто написать LEDBAT как CC для TCP, все современные ОС поддерживают.

думаю они не стали лезть в ОС (начиная с wxp) с новым CC для TCP по многим причинам: новый протокол не обкатан и сломает системный работающий CC, нужно для каждой ОС тестировать внедрение нового СС, противоречит идеологии utorrent как меленького клиента, и т.п. ...