Я работаю над решением .net, которое выполняется полностью внутри одной сети. Когда пользователи вносят изменения в систему, я хочу запустить анонс, и все остальные услышат его и будут действовать соответствующим образом. Есть ли способ, которым мы можем транслировать такие сообщения (например, UDP позволит вам делать), сохраняя при этом гарантированную доставку (например, TCP)?
Это небольшая сеть (30-ти клиентов), если это будет иметь значение.
Почти все игры нуждаются в быстро реагирующих свойствах (и, в меньшей степени, свойствах без установления соединения) UDP и надежности TCP. То, что они делают, это построение собственного надежного протокола поверх UDP. Это дает им возможность просто разбивать пакеты на все и, возможно, сделать их надежными.
Надежная пакетная система, как правило, представляет собой простую систему с повторением до подтверждения, более простую, чем TCP, но существуют протоколы, выходящие за пределы того, что может предложить TCP.
Ваша ситуация звучит очень просто. Вы, вероятно, сможете сами сделать самое чистое решение - просто попросите каждого клиента отправить ответ "Я слышал вас", и сервер продолжает пытаться, пока он не получит его (или не сдастся).
Если вы хотите чего-то большего, большинство пользовательских библиотек протоколов находятся на С++, поэтому я не уверен, насколько они будут полезны для вас. Тем не менее, мои знания здесь несколько лет - возможно, некоторые протоколы были перенесены. Хм... RakNet и enet - две библиотеки C/С++, которые приходят на ум.
Взгляните на sctp, который имеет комбинацию функций tcp и udp. Доступны окна реализация.
Вы можете использовать Spread для группового общения.
@epatel - второй вариант предложения SCTP (я проголосовал, но не могу прокомментировать еще такой материал).
SCTP обладает множеством отличных функций и гибкости. Вы можете разделить ваше соединение на несколько потоков и выбрать надежность каждого из них и заказать его или нет. В качестве альтернативы с расширением Partially Reliability вы можете контролировать надежность для каждого сообщения.
Возможно, вы захотите заглянуть в RFC 3208 "Спецификация надежного транспортного протокола PGM".
Вот тезис:
Прагматическая общая многоадресная рассылка (PGM) надежный многоадресный транспорт
протокол для приложений, требующих упорядоченный или неупорядоченный,
данные без дубликатов, многоадресной рассылки доставка из нескольких источников в
несколько приемников. Гарантия PGM что получатель в группе либо получает все пакеты данных от передачи и ремонта, или возможность обнаружения неустранимых данных потеря пакетов. PGM специально предназначенное для многоадресные приложения с базовыми требования к надежности. Его центральная Цель проекта - простота с должным учетом масштабируемость и эффективность сети.
Вы можете использовать Message Broker, например ActiveMQ.
Опубликуйте свои сообщения в теме и попросите клиентов зарегистрировать простую подписку на эту тему, чтобы они не пропустили никаких сообщений, даже если они не подключены к сети.
Apache ActiveMQ является брокером сообщений написанный на Java вместе с полным JMS-клиент. Однако Apache ActiveMQ предназначенные для связи по ряду протоколов, таких как Stomp и OpenWire вместе с поддержкой количество различных языковых клиентов.
Поддержка клиентской платформы включает С# и .net
Вы можете реализовать свое собственное поведение, подобное TCP, на уровне приложения.
Итак, например, вы отправляете широковещательную рассылку UDP, но затем ожидаете ответа от каждого хоста. Если вы не получили ответа в течение X секунд, отправьте другое и так далее, пока не достигнете своего порога. Если пороговое значение достигнуто (т.е. хост не ответил вообще), сообщите об ошибке.
Чтобы сделать это, вам понадобится предварительно определенный список хостов, чтобы ожидать откликов.
Трансляция - это не то, что вы хотите. Поскольку в этой сети могут быть и возможно подключены устройства, которые не заботятся о вашем сообщении, вы должны использовать Multicast. В отличие от широковещательных сообщений, которые должны быть отправлены и обработаны каждым клиентом в сети, сообщения многоадресной рассылки доставляются только заинтересованным клиентам (т.е. Тем, у кого есть намерение получить этот тип сообщения и действовать на нем).
Если вы позже масштабируете эту систему так, чтобы ее нужно было маршрутизировать по большой сети, многоадресная рассылка может масштабироваться до этого, тогда как трансляция не будет, поэтому вы получите преимущество масштабируемости, которое вы можете оценить позже. Тем временем вы устраняете ненужные накладные расходы в коммутаторах и других устройствах, которым не нужно видеть эти сообщения "что-то изменилось".
Создайте TCP-сервер. Попросите каждого клиента подключиться. В своем TCP-протоколе с клиентами создайте каждый пакет с 2-байтовым префиксом общего размера следующего сообщения.
Затем клиенты вызывают read(max_size=2) в сокете, чтобы определить размер следующего сообщения, а затем read(max_size=s), чтобы собрать сообщение.
Вы получаете надежные, упорядоченные сообщения, простые. Для этого вам не нужна инфраструктура обмена сообщениями.
Вы определенно хотите посмотреть Pragmatic General Multicast:
В то время как TCP использует ACK для подтверждения групп отправленных пакетов (что было бы неэкономичным по многоадресной рассылке), PGM использует концепцию Negative Acknowledgements (NAKs).
Для дальнейшего G-diving, термин, который вы ищете, надежная многоадресная рассылка. Также посмотрите Multipath TCP.
Что вы можете сделать, так это то, что после широковещательной передачи клиенты инициируют подключения tcp. В противном случае вам просто нужно сохранить список всех клиентов и инициировать подключения к каждому клиенту самостоятельно.
Я думаю, что есть три варианта, в общем говоря:
Yoy должен взглянуть на спецификацию Norm (NACK-Oriented Reliable Multicast). Вы можете найти информацию о Norm здесь.
Протокол NORM предназначен для обеспечить сквозной надежный транспорт объемных объектов данных или потоков универсальная маршрутизация IP-адресов и экспедиторские услуги. NORM использует избирательное, отрицательное подтверждение (NACK) для транспорта надежности и предлагает дополнительные протокольные механизмы для проведения надежные многоадресные сеансы с ограниченная "априорная" координация между отправители и приемники
Это несколько хорошо известно в военном мире.
Зачем строить что-то с нуля, если вы можете использовать библиотеку? Специально для такого небольшого проекта?
Попробуйте использовать Emcaster, который сам использует надежную многоадресную рассылку - PGM, написан на .NET и с полным исходным кодом. Вы получите хороший паб/подмодуль с возможностью фильтрации темы. Или вы можете узнать из кода, как это сделать, и основывать свое собственное расширение на нем.
Я думаю, что наиболее раздражающей особенностью TCP в этих сценариях является способность/способ сортировки входящих пакетов в их первоначальный порядок - понятие потока. Вы не можете прочитать байт до байта до его прибытия.
Если вы можете жить без него, у вас есть шанс получить свой протокол, быстрый и надежный, но не для заказа пакетов! Их просто невозможно обойти, потому что вы не можете заказать свои байты, пока не получите другую копию потерянного пакета, что является основным компромиссом.
выполните многоадресную рассылку RDP.