Двухфазный протокол с низкой задержкой

Question

Я смотрю рекомендации о том, как добиться низкой задержки для следующего сетевого протокола:

1. Алиса отправляет запрос на получение информации множеству пиров, выбранных случайным образом из очень большого пула.
2. Каждый узел отвечает маленьким пакетом <20 КБ. </li>
3. Алиса объединяет ответы и соответственно выбирает партнера.
4. Алиса и выбранный одноранговый узел затем переходят ко второй фазе протокола, посредством чего выполняется последовательность из 2 запросов и ответов.
5. Повторить с 1.

Учитывая, что шаги 1 и 2 не обязательно должны быть надежными (если процент ответов возвращается, мы переходим к шагу 3) и что 1, по сути, является многоадресной, эта часть протокола, похоже, подходит для настройки UDP подключение TCP к этим одноранговым узлам добавило бы двустороннее добавление.

Однако шаг 4 должен быть надежным - мы не можем допустить потери пакетов во время последующих запросов / ответов.

Проблема, с которой я сталкиваюсь, заключается в том, что UDP подходит для 1 и 2, а протокол TCP - для 4. Соединение с каждым равноправным узлом, выбранным в 1, является медленным, особенно потому, что мы стремимся передавать только 20 КБ, однако UDP не может быть допущен для шага 4. Рукопожатие для равноправного участника, выбранного в 4., потребуется дополнительная поездка туда и обратно, что по сравнению с 3 поездками туда и обратно все еще значительно увеличивает общее время.

Существует ли какая-нибудь гибридная схема, посредством которой вы можете выполнять TCP-квитирование при передаче небольшого количества данных? (Рукопожатие может быть объединено в 1 и 2 и, следовательно, не добавляет дополнительного времени в оба конца.)

Есть ли название для таких протоколов? Что я должен прочитать, чтобы поближе познакомиться с такими проблемами?

Дополнительная информация:

• Предполагается, что участники случайным образом распределены по всему земному шару и подключены через Интернет.
• Пул, выбранный на шаге 1., имеет порядок 1000 адресов, а выборка из пула - от 10 до 100.

Answer 1

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

Я бы сказал, что UDP не подходит для ранней части вашего протокола.Вы не можете просто передать один пакет большому количеству хостов в Интернете (хотя вы можете сделать это в типичных локальных сетях).Полезная нагрузка 20 КБ - это не та вещь, которую вы обычно можете передавать в одной дейтаграмме в любом случае, и в тот момент, когда сообщения не помещаются в одну дейтаграмму, UDP теряет большую часть своей привлекательности, потому что вы начинаете заново изобретать TCP (плохо).

Вероятно, самое простое, что вы можете сделать, - это основать свою систему на HTTP и работать с реализациями, которые включают все различные ускорения, которые Google (в основном) внедряет в разработку HTTP.Это включает в себя TCP Fast Open и тому подобное.Инициируйте соединения с выбранными вами серверами;некоторые будут реагировать быстрее, чем другие: используйте это в своих интересах, выбирая самые быстрые.Кстати, не стоит недооценивать важность эффективной реализации по сравнению с теоретическим временем прохождения туда и обратно.

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

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