Рост количества потерь пакетов со временем.

Защита сети (Интернет) от ненужных запросов (шалостей).

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

Есть шанс, что ошибка в твоей программе.

Нет.

Да.

Это ни при чем. Просто, в контроллере защита. Сейчас уже сеть не по-сканнируешь, как раньше - в поисках расшаренных устройств!

я запускаю программу, скажем раз 10, потом открываю какие нибудь сайты и т.д. youtube например. И через некоторое время ~ 30 минут количество потерь в секунду резко увеличивается.

Видосики качаются и забивают всю ширину канала.. твои удп пакеты дропаются так как не успевают отправиться (килобиты в секунду все потратил ютуб)

Я делаю ifconfig wlp4s0 down && ifconfig wlp4s0 up и всё становиться сново нормально, причём с открытыми сайтами.

случается разрыв соединения и ютуб перестаёт качать данные на какое-то время

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

Ну оно точно теряется? Wireshark/tcpdump проверяли что на выходе пакеты есть, а на входе нет?

Попробуй повторить с iperf3, тогда сможешь исключить свою криворукость.

Я пишу udp с гарантией доставки

Почему бы тогда не использовать tcp?

Может, QoS чудит?

int tos = IPTOS_CLASS_CS7;
if(setsockopt(fd, IPPROTO_IP, IP_TOS, (void*)&tos, sizeof(int)) < 0) return -1;

Помогло.

Ответ такой же как если бы linux-user написал на форум что у него wine падает, а вы бы ему ответили, что нужно поставить windows что бы играть.

Почему бы тогда не использовать tcp?

Потому что в TCP пакеты приходят в определённом порядке и это не отключаемо, а иногда это не нужно.

О, интересно. Возможно, мне тоже что-то такое пригодится
https://en.wikipedia.org/wiki/Type_of_service

Ответ такой же как если бы linux-user написал на форум что у него wine падает, а вы бы ему ответили, что нужно поставить windows что бы играть.

Мотивация пользоваться wine простая: не тратить ресурсы на вторую ОС, будь то dual boot или виртуалка). А они - ресурсы - значительные, как по железу, так и по времени.

А вот мотивация использования UDP в случае требования гарантированной доставки непонятна.

Почему бы тогда не использовать tcp?

Потому что в TCP пакеты приходят в определённом порядке и это не отключаемо, а иногда это не нужно.

А чем это мешает?

А чем это мешает?

Тем что это создает ощутимые задержки и снижает скорость. Примеры использования разные - в шутерах, при передаче файлов по сети кусками (не последовательно конечно же) и т.д.

Тем что это создает ощутимые задержки и снижает скорость.

Ощутимые для чего? ТС так и не раскрыл свой Use Case, с чего ты взял что для его конкретного случае задержки будут ощутимыми?

Примеры использования разные - в шутерах, при передаче файлов по сети кусками (не последовательно конечно же).

Передача файлов по кускам - это для чего? Сетевой стек и так бьёт данные на куски. Другие подходы (типа торрентов) точно требуют нужной последовательности. А там где пропускная способность является важным требованием (типа бекапов в датацентрах) используют совершенно другие подходы.

Игры - либо передают дельту, и тогда последовательность важна, либо абсолютную позицию, и тогда пакеты можно терять (думаю, с эффектом «телепортации» при плохой сети многие геймеры сталиквались).

Мне кажется ТС просто пишет что-то для чего используется UDP, но забыл спроектировать решение так, чтобы оно нормально работало с потерей пакетов.

В дельте в играх не нужна последовательность, при потере пакета шлётся новая дельта, т.к промежуточные состояния уже неактуальны.
То же самое в voip - тебе не нужны старые пакеты.

А там где пропускная способность является важным требованием (типа бекапов в датацентрах) используют совершенно другие подходы.

И какие? Всё что не TCP обычно использует UDP.
Изредка могут использоваться другие IP протоколы, но обычно в этом нет смысла.

Тогда почему quic использует udp? Ему гарантированная доставка не нужна по твоему?
TCP это протокол передачи ПОТОКА (SOCK_STREAM) с гарантированной доставкой.
Когда тебе не нужен обязательно именно stream, могут использоваться другие способы.
всякие дельты, rtp - один из примеров. Там тебе не нужны неактуальные данные, потому stream неэффективен

Эффект называется warp, warping. Это раз. Дельту терять можно. Это два.

А там где пропускная способность является важным требованием (типа бекапов в датацентрах) используют совершенно другие подходы.

И какие?

Настройки QoS.

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

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

Позволь два вопроса:

1. Какой прирост производительности ты расчитываешь получить при такой реализации?
2. Для каких сценариев этот прирост будет стоить потраченных усилий?

Я просто оставлю это здесь:

https://stackoverflow.com/questions/5485756/can-udp-retransmit-lost-data

Also note that it is easy to implement your own stack on top of UDP that performs worse than TCP

https://stackoverflow.com/questions/107668/what-do-you-use-when-you-need-reliable-udp

But in (very!) general terms I think you’re going to have to try really hard to beat tcp for speed, unless you can make some hard assumptions about the data that you’re trying to send.

И хоть какие-то бенчмарки.

https://www.sciencedirect.com/science/article/pii/S1877050917311754 - Simulated performance of TCP, SCTP, DCCP and UDP protocols over 4G network

Conclusion:

The simulation shows that DCCP outperforms other protocols in terms of throughput, jitter, and delay. On the other hands, TCP gives a higher packet delivery rate and minimum packet loss count due to its connection oriented feature. At the end, for multimedia applications where the packet loss is difficult to be handled, the developers should opt for TCP, otherwise DCCP is the best choice with better throughput in MPEG-4 video streaming over the LTE environment.

Прирост зависит от потери пакетов. В tcp потеря каждого пакета может застопорить весь стрим на какое-то время, здесь же сколько бы пакетов не потерялось - они отправятся повторно после одного ответа. Я подобное реализовывал, когда лежал в больнице после операции и использовал интернет через iodine на симке без денег. На этом мобильном операторе частично работает udp, потому я пытался организовать передачу файлов через udp. Там правда была особенность - в одну сторону пакеты прохрдили только раз в секунду, потому такой механизм очень даже повышал скорость передачи относительно пеекачивания через iodine raw + tcp. Во сколько раз? Ну, допустим по tcp у меня было 10-100 килобайт в секунду, а специальным udp сервер-клиентом 800-1500. И наверняка можно было сделать лучше, но тогда этого было достаточно.
Что касается потраченных усилий - не думаю, что пара часов написания скриптов на питоне - это так страшно, какой бы цель не была. Мне тогда конкретно это позволило смотреть выкаченные через VPS видосики - цель достингнута, времени не жалко - всё равно я лежал в больнице

Последняя ссылка не работает
Нет, очевидно что если ты будешь имплементировать такой же tcp поверх udp, то он может работать хуже за счёт того, что про tcp уже знают роутеры, для него уже будет оптимальнее работать QoS и он даже может быть аппаратно ускорен, да ещё и место на udp заголовок тратится.
Но любые кейсы, где тебе нужен не условно непрерывный «поток», а нечто другое, например просто переданный фрагментам огромный файл или voip данные в реальном времени, или состояние игрового мира с минимальной задержкой - вряд ли tcp окажется лучшим решением

реализовывал, когда лежал в больнице после операции и использовал интернет через iodine на симке без денег
пара часов написания скриптов на питоне
наверняка можно было сделать лучше, но тогда этого было достаточно
времени не жалко - всё равно я лежал в больнице
вряд ли tcp окажется лучшим решением

— Слушай, а… сколько сейчас времени, ты не знаешь? Так, примерно, можешь почувствовать?
— Ладно, подожди. Заткнись, подожди…
— Я говорю, время сколько?..
— Сядь, сядь, подожди. Дай, блин…
— Да мне вообще всё равно, который час там, чего там сейчас… Чё там творится, мне всё равно, понимаешь?
— Ну не говори лишнего тогда, сядь.

tcp вместо udp странно советовать, но почему бы не взять QUIC ? Как раз то, что вы хотите, но поддерживается примерно всем.