Трансляция как UDP с надежностью TCP

сделать многоадресную рассылку RDP.

Что вы можете сделать, так это то, что после трансляции клиенты инициирует TCP-соединения. В противном случае вам просто нужно вести список всех клиентов и самостоятельно инициировать подключения к каждому клиенту.

В общем, я думаю, есть три варианта:

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

Вы можете использовать Распространять для группового общения.

Вы можете реализовать собственное поведение, подобное TCP, на уровне приложения.

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

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

Почти все игры нуждаются в свойствах быстрого реагирования (и, в меньшей степени, в свойствах без установления соединения) UDP и надежности TCP. Что они делают, так это создают свой собственный надежный протокол поверх UDP. Это дает им возможность просто рассылать пакеты куда угодно и, при необходимости, делать их надежными.

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

Ваша ситуация кажется очень простой. Вы, вероятно, сможете сами принять самое чистое решение - просто заставьте каждого клиента отправлять ответ «Я слышал вас» и пусть сервер продолжает попытки, пока он его не получит (или не сдастся).

Если вы хотите чего-то большего, большинство пользовательских библиотек протоколов написаны на C++, поэтому я не уверен, насколько они вам пригодятся. Однако моим знаниям здесь несколько лет - возможно, некоторые протоколы уже были перенесены. Хм ... RakNet и enet - две библиотеки C / C++, которые приходят на ум.

Взгляните на sctp, который имеет комбинацию функций tcp и udp. Доступен windows выполнение.

Вам следует взглянуть на спецификацию Norm (NACK-Oriented Reliable Multicast). Вы можете найти информация о Норме здесь.

The NORM protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgement (NACK) mechanism for transport reliability and offers additional protocol mechanisms to conduct reliable multicast sessions with limited "a priori" coordination among senders and receivers

Это довольно хорошо известно в военном мире.

Нормы спецификации.

Норма Источник

@epatel - я поддерживаю предложение SCTP (я проголосовал, но пока не могу комментировать, так что дополнительные сведения здесь).

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

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

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

Возможно, вы захотите изучить RFC 3208 «Спецификация надежного транспортного протокола PGM».

Вот аннотация:

Pragmatic General Multicast (PGM) is a reliable multicast transport
protocol for applications that require ordered or unordered,
duplicate-free, multicast data delivery from multiple sources to
multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency.

Зачем создавать что-то с нуля, если можно использовать библиотеку? Специально для такого небольшого проекта?

Попробуйте использовать Emcaster, который сам использует надежный многоадресный обмен сообщениями - PGM, написан на .NET и с полным исходным кодом. Вы получите хороший движок pub / sub с легкодоступной фильтрацией тем. Или вы можете узнать из кода, как это сделать, и создать на его основе собственное расширение.

Я думаю, что наиболее раздражающей особенностью TCP в этих сценариях является возможность / способ сортировки входящих пакетов в их исходном порядке - концепция потока. Вы не можете прочитать байт, пока байт не поступил.

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

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

Затем клиенты вызывают read(max_size=2) в сокете, чтобы определить размер следующего сообщения, а затем read(max_size=s) для сбора сообщения.

Вы получаете надежные, упорядоченные сообщения, простые. Для этого вам не нужна структура обмена сообщениями.

Вы можете использовать брокер сообщений, например ActiveMQ.
Опубликуйте свои сообщения в теме и попросите клиентов зарегистрировать постоянные подписки на эту тему, чтобы они не пропустили ни одного сообщения, даже если они не в сети.

Apache ActiveMQ is a message broker written in Java together with a full JMS client. However Apache ActiveMQ is designed to communicate over a number of protocols such as Stomp and OpenWire together with supporting a number of different language specific clients.

Поддержка клиентской платформы включает C# и .net.

Вы бы определенно захотели заглянуть в Практическая универсальная многоадресная передача:

While TCP uses ACKs to acknowledge groups of packets sent (something that would be uneconomical over multicast), PGM uses the concept of Negative Acknowledgements (NAKs).

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