Делаю прогу для копирования файла по UDP. Отправитель разбивает файл на блоки и шлет получателю.

ТЗ кратко:
Отправитель каждые 20 мс отправляет один пакет с запросом подтверждения (MSG_TYPE_DATA_ASK) и окно из N (размер окна) пакетов MSG_TYPE_DATA (в каждом очередной блок файла, если есть запрос потерянных то сначала их). Отправка может начаться раньше, если придет подтверждение последнего MSG_TYPE_DATA_ASK. В этом случае отсчет 20 мс начинается с отправки первого пакета.
Получатель сохраняет принятые блоки и следит за порядком их поступления. Если получен блок не по порядку, то пропущенные заносятся в таблицу пропущенных. При получении ранее пропущенного он убирается из таблицы.
Получатель отправляет подтверждение MSG_TYPE_COMMIT (номер последнего принятого и список пропущенных) при получении MSG_TYPE_DATA_ASK и при последнего блока (прием завершен).

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

Вопрос: как управлять размером окна?

Надо придумать какую-то функцию или алгоритм, который в момент получения очередного подтверждения (MSG_TYPE_COMMIT) рассчитает на сколько увеличить/уменьшить текущее значение N.
При расчете можно использовать:
Текущее значение размера окна (N).

Сколько пакетов доставлено на текущий момент.

Количество потерянных пакетов в подтверждении.

Количество потерянных пакетов всего.

Возможно еще какая-то статистика накопленная отправителем в процессе отправки.

Пока придумал просто уменьшать размер окна на кол-во потерянных пакетов. В случае если потерь нет - увеличивать на 10%.
На коротких расстояниях (< 2 мс) оно нормально должно заработать. Подтверждение доставки предыдущего окна будет приниматься сразу после отправки текущего окна.

Самая большая проблема с большими расстояниями (> 20 мс). Там поправочные изменения будут приходить раз в 20 мс, интервал отправки окон, т.е. корректировка N будет происходить в десятки раз реже, чем на коротких.

Понимаю что надо как-то учесть время, но тут есть проблемы точных замеров из-за дискретности штатных часов 1-10 мс, а так же из-за вытесняющей многозадачности ОС, т.е. измеряющий поток может банально ожидать получения своего кванта процессорного времени.
Поэтому при измерении времени вводим погрешность 10 мс (или +/- 5 мс)

maytonВ гитхабе есть?
Пока нет, не доделал еще. Закончу - выложу. Будет с акторами :)

maytonТвою разработку я поддерживаю на уровне энтузиазма, но не очень понимаю что получится
в конце. Будет ли это твой транспортный протокол поверх протокола коротких сообщений? Или что-то другое?
Я решил есть слона по частям :)

Конкретно это - создание транспортного протокола передачи сообщений поверх UDP. Плюс побаловаться с акторами. Заодно еще раз попытаться выжать гигабит в локалке .

На одном конце запускаем ожидание приема на заданном порту и сохранение принятого в заданную папку



На другом отправляем


Потом запущу прием дома на cubie и буду слать туда бэкапы. Почти продакшн :)

Basil A. Sidorov, спасибо за ссылки. Натолкнул на мысль.

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

Думаю надо отталкиваться от доли потерь, но не с начала отправки (например гигабайт отправляется и в конце резко потери возросли), а за последние 1-2 секунды, может даже меньше. Т.е. вычисляем долю потерь, если она ниже нормы - увеличиваем окно, выше - уменьшаем.
Тут встает вопрос подбора нормы потерь, думаю можно будет подобрать методом научного тыка. Буду думать в этом направлении.

PS MTU учел, есть проверка хэша всего файла и каждого пакета в отдельности, есть шифрование, есть рандомная составляющая для разнообразия шифрованных пакетов с одинаковым содержимым. Т.к. это за рамками вопроса топика, поэтому не стал усложнять ненужными подробностями.

maytonВ гитхабе есть?
Сделал папку , пока там только описаловка основных моментов.

maytonDima Tпропущено...

Сделал папку , пока там только описаловка основных моментов.
Хм... не знаю. У меня LibreOffice и он открывает этот документ как минимум странно.
Ты мог-бы его .. экспортировать в что-то очень простое.
Перепробовал все варианты. Не заточен гитхаб на форматированный текст, только их самодельное форматирование. В PDF`е показывает.

maytonЯ кстати придумал подход при котором тебе вообще никакое окно не нужно.
Делись. Только учти с таймерами все плохо, погрешность 10 мс. Т.е. я могу быстро послать окно пакетов и долгая пауза. Я выбрал 20 мс, т.к. это будет относительно стабильная частота срабатывания.
Моя мысль в том чтобы нащупать максимальный размер окна, который можно за раз отправить и придерживаться его.

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

вся оптимизация у тебя будет лишь в уменьшении переотправки потерявшихся блоков
Для учета MTU я просто ограничиваю размер UDP пакета. Никакими raw-сокетами MTU ты не увеличишь, это жестко зашитое ограничение. В случае превышения происходит фрагментация или пакет теряется.
Все сетевое оборудование оперирует пакетами в единицу времени, поэтому пакет надо максимально наполнить чтобы получить максимальную скорость передачи.