Есть ли “хороший” способ справиться с повторной сборкой многоадресных рассылок из нескольких источников?

Question

В настоящее время я перерабатываю наш существующий проприетарный код оболочки сокета для использования boost asio, чтобы он мог выполнять часть тяжелой работы за нас.Возможно, самой сложной областью нашего существующего кода является код обработки многоадресной рассылки.Код позволяет нашим серверам среднего уровня (которых может быть много в одной системе) отправлять многоадресные рассылки на клиентские ящики, которые используют их для представления обновлений пользователям системы.

Причина, по которой код является сложным и подверженным ошибкам, заключается в том, что он использует несколько необработанных буферов для повторной сборки потоков многоадресной рассылки в соответствии с тем, откуда они пришли.Похоже, что даже с Boost.Asio Мне придется столкнуться с этой же проблемой, поэтому, прежде чем я застряну, я подумал, что стоило бы спросить, как другие люди справлялись с этой ситуацией.

Это похоже на очень распространенный вариант использования.Есть ли там что-нибудь, что может помочь мне выполнить эту работу без того кода, который у меня есть сейчас?Или существует установленный шаблон C ++ (Boost или другой), который может выполнять такого рода работу?

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

Заранее спасибо за любые мысли по этому поводу.

Джейми

Answer 1

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

• Если вы используете необработанную многоадресную рассылку UDP, вы, вероятно, выполняете какую-то последовательность протоколов в пользовательском пространстве, чтобы иметь дело с потерянными или дублированными пакетами.Любую оптимизацию, которую вы хотите выполнить, не поддавайтесь искушению чтобы разорвать разделение между вашим приложением и уровнем протокола.
• std::vector, для большинства целей идентичен необработанному динамически выделяемому символьному буферу.Не уклоняйтесь от его использования только потому, что это уровень абстракции.Однако есть два случая, когда вам следует избегать этого:
  • Если вам сойдет с рук статически выделенные буферы
  • Если вам нужно передать право собственности на буфер ниже по потоку (хотя, если вы тщательно проектируете, swap() может быть достаточным)
• Предварительное распределение - ваш друг.Если у вас есть набор буферов, доступных для использования при поступлении данных, вы можете удалить большую часть динамического распределения с быстрого пути выполнения.
• Сведите к минимуму копии в памяти.Если вы можете обрабатывать данные в одном стеке вызовов, у вас есть шанс избежать копирования.Если вам нужно передать данные в другой поток, вы можете быть вынуждены скопировать данные.
• Если ваше приложение может обрабатывать фрагментированные буферы (вместо того, чтобы объединять все данные в один буфер), загляните в writev и readv.

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