Broadcast wie UDP mit der Zuverlässigkeit von TCP

https://stackoverflow.com/questions/31572

09-06-2019
|

Frage

Ich arbeite an einer .net-Lösung, die vollständig in einem einzigen Netzwerk ausgeführt wird.Wenn Benutzer eine Änderung am System vornehmen, möchte ich eine Ankündigung starten, damit alle anderen sie hören und entsprechend handeln.Gibt es eine Möglichkeit, Nachrichten wie diese auszusenden (wie es UDP ermöglicht) und gleichzeitig die garantierte Zustellung beizubehalten (wie TCP)?

Dies geschieht in einem kleinen Netzwerk (ca. 30 Clients), falls das einen Unterschied machen würde.

Lösung

Fast alle Spiele benötigen die reaktionsschnellen Eigenschaften (und in geringerem Maße die verbindungslosen Eigenschaften) von UDP und die Zuverlässigkeit von TCP.Sie bauen ihr eigenes zuverlässiges Protokoll auf UDP auf.Dies gibt ihnen die Möglichkeit, Pakete einfach an einen beliebigen Ort zu verteilen und sie optional auch zuverlässig zu machen.

Das zuverlässige Paketsystem ist normalerweise ein einfaches System mit Wiederholung bis zur Bestätigung, das einfacher als TCP ist, aber es gibt Protokolle, die weit über das hinausgehen, was TCP bieten kann.

Ihre Situation klingt sehr einfach.Wahrscheinlich können Sie selbst die sauberste Lösung finden – lassen Sie einfach jeden Client eine „Ich habe Sie gehört“-Antwort zurücksenden und lassen Sie den Server es so lange versuchen, bis er sie erhält (oder aufgibt).

Wenn Sie mehr möchten: Die meisten benutzerdefinierten Protokollbibliotheken sind in C++, daher bin ich mir nicht sicher, welchen Nutzen sie für Sie haben werden.Allerdings ist mein Wissen hier schon ein paar Jahre alt – vielleicht wurden einige Protokolle inzwischen portiert.Hmm...RakNet und enet sind zwei C/C++-Bibliotheken, die mir in den Sinn kommen.

Andere Tipps

Schauen Sie mal rein sctp das über eine Kombination aus TCP- und UDP-Funktionen verfügt.Es gibt ein Fenster Implementierung verfügbar.

Du könntest benutzen Verbreiten Gruppenkommunikation betreiben.

@epatel – Ich schließe mich dem SCTP-Vorschlag an (ich habe dafür gestimmt, kann aber noch keinen Kommentar abgeben, deshalb hier noch mehr).

SCTP bietet viele großartige Funktionen und Flexibilität.Sie können Ihre Verbindung in mehrere Streams unterteilen und die Zuverlässigkeit jedes einzelnen Streams auswählen und festlegen, ob er geordnet ist oder nicht.Alternativ mit dem Teilweise Zuverlässigkeit Mit der Erweiterung können Sie die Zuverlässigkeit pro Nachricht steuern.

Broadcast ist nicht das, was Sie wollen.Da an dieses Netzwerk Geräte angeschlossen sein könnten und dies wahrscheinlich auch tun wird, denen Ihre Nachricht egal ist, sollten Sie Multicast verwenden.Im Gegensatz zu Broadcast-Nachrichten, die an jeden Client im Netzwerk gesendet und von diesem verarbeitet werden müssen, werden Multicast-Nachrichten nur an interessierte Clients übermittelt (dh solche, die die Absicht haben, diesen bestimmten Nachrichtentyp zu empfangen und darauf zu reagieren).

Wenn Sie dieses System später so skalieren, dass es über ein großes Netzwerk geroutet werden muss, kann Multicast darauf skaliert werden, Broadcast hingegen nicht, sodass Sie einen Skalierbarkeitsvorteil erhalten, den Sie später vielleicht zu schätzen wissen.Gleichzeitig vermeiden Sie unnötigen Overhead bei Switches und anderen Geräten, die diese „etwas hat sich geändert“-Meldungen nicht sehen müssen.

Vielleicht möchten Sie einen Blick darauf werfen RFC 3208 „PGM Reliable Transport Protocol-Spezifikation“.

Hier ist die Zusammenfassung:

Pragmatischer General Multicast (PGM) ist ein zuverlässiger Multicast -Transport
Protokoll für Anwendungen, die geordnet oder ungeordnet sind,
Doppelfreie, multicast-Datenabgabe von mehreren Quellen bis
mehrere Empfänger.PGM garantiert, dass ein Empfänger in der Gruppe entweder alle Datenpakete aus Übertragungen und Reparaturen empfängt oder nicht wiederherstellbare Datenpaketverluste erkennen kann.PGM ist speziell als praktikable Lösung für Multicast -Anwendungen mit grundlegenden Zuverlässigkeitsanforderungen gedacht.Das zentrale Konstruktionsziel ist die Einfachheit des Betriebs unter Berücksichtigung der Skalierbarkeit und der Netzwerk -Effizienz.

Sie könnten einen Message Broker verwenden, z ActiveMQ.
Veröffentlichen Sie Ihre Nachrichten zu einem Thema und lassen Sie die Kunden dauerhafte Abonnements für das Thema registrieren, damit sie keine Nachrichten verpassen, auch wenn sie nicht online sind.

Apache Activemq ist ein Message Broker, der zusammen mit einem vollständigen JMS -Client in Java geschrieben wurde.Apache Activemq wurde jedoch entwickelt, um über eine Reihe von Protokollen wie Stomp und Openwire zu kommunizieren, zusammen mit der Unterstützung einer Reihe verschiedener sprachspezifischer Kunden.

Die Unterstützung der Client-Plattform umfasst C# und .net

Sie könnten Ihr eigenes TCP-ähnliches Verhalten auf der Anwendungsebene implementieren.

So würden Sie beispielsweise den UDP-Broadcast versenden, dann aber eine Antwort von jedem Host erwarten.Wenn Sie innerhalb von X Sekunden keine Antwort erhalten haben, senden Sie eine weitere und so weiter, bis ein gewisser Schwellenwert erreicht ist.Wenn der Schwellenwert erreicht ist (d. h.der Host hat überhaupt nicht geantwortet), dann melden Sie einen Fehler.

Dazu benötigen Sie jedoch eine vordefinierte Liste von Hosts, von denen Sie Antworten erwarten können.

Erstellen Sie einen TCP-Server.Lassen Sie jeden Client eine Verbindung herstellen.Erstellen Sie in Ihrem TCP-Protokoll mit den Clients jedes Paket mit einem 2-Byte-Präfix der Gesamtgröße der folgenden Nachricht.

Die Kunden rufen dann an read(max_size=2) auf dem Socket, um die Größe der nächsten Nachricht zu bestimmen, und dann read(max_size=s) um die Nachricht zu sammeln.

Sie erhalten zuverlässige, geordnete Nachrichten, ganz einfach.Hierfür benötigen Sie kein Messaging-Framework.

Das würdest du definitiv hineinschauen möchte Pragmatischer allgemeiner Multicast:

Während TCP ACKs verwendet, um Gruppen gesendeter Pakete zu bestätigen (etwas, das wäre). unwirtschaftlich gegenüber Multicast) verwendet PGM das Konzept der negativen Bestätigungen (NAKs).

Für weitere G-Tauchen, der Begriff, den Sie suchen, ist zuverlässiger Multicast.Schauen Sie auch mal vorbei Multipath-TCP.

Was Sie tun können, ist, dass nach der Übertragung die Kunden Initiieren Sie die TCP-Verbindungen.Andernfalls müssen Sie lediglich eine Liste aller Clients führen und die Verbindungen zu jedem Client selbst initiieren.

Ich denke, es gibt im Großen und Ganzen drei Möglichkeiten:

Anstatt UDP zu übertragen, könnten Sie eine Entität erstellen (einen Thread, Prozess, Server, Dienst oder was auch immer in Ihrer Lösung vorhanden ist), die eine Liste von Abonnenten führt und ihnen Unicast-UDP-Nachrichten sendet.
Verwenden Sie UDP-Multicast, aber Sie müssen einen Mechanismus schreiben, der für eine zuverlässige Zustellung sorgt (z. B. Wiederholungsversuche, Zeitüberschreitungen usw.).Das bedeutet auch, dass Sie eine Antwort von Ihren Kunden erhalten müssen.
Wenn Sie keine Angst vor experimentellen Transportprotokollen haben, sollten Sie nachsehen Hier Für Vorschläge.,

Sie sollten einen Blick auf die Norm-Spezifikation (NACK-Oriented Reliable Multicast) werfen.Sie können finden Informationen zu Norm finden Sie hier.

Das NORM-Protokoll bietet einen endgültigen zuverlässigen Transport von Bulk-Datenobjekten oder Streams über generische IP-Multicast-Routing- und Weiterleitungsdienste.Norm verwendet einen selektiven Mechanismus für negative Anerkennung (negative Anerkennung) für die Transportzuverlässigkeit und bietet zusätzliche Protokollmechanismen, um zuverlässige Multicast -Sitzungen mit begrenzter "a priori" -Koordination zwischen Absendern und Empfängern durchzuführen

Es ist in der Militärwelt ziemlich bekannt.

Normspezifikationen.

Normquelle

Warum etwas von Grund auf neu erstellen, wenn Sie eine Bibliothek verwenden können?Besonders für so ein kleines Projekt?

Probieren Sie es aus Emcaster das selbst zuverlässiges Multicast-Messaging (PGM) verwendet, in .NET geschrieben ist und über vollständige Quellcodes verfügt.Sie erhalten eine schöne Pub/Sub-Engine mit sofort verfügbarer Themenfilterung.Oder Sie können anhand des Codes lernen, wie es geht, und Ihre eigene Erweiterung darauf aufbauen.

Ich denke, das irritierendste Merkmal von TCP in diesen Szenarien ist die Fähigkeit/Art, eingehende Pakete in ihrer ursprünglichen Reihenfolge zu sortieren – das Konzept eines Streams.Sie können ein Byte erst dann lesen, wenn das Byte vor dem Eintreffen vorliegt.

Wenn Sie ohne leben können, haben Sie die Chance, Ihr Protokoll schnell und zuverlässig zu erhalten, aber nicht für die Bestellung von Paketen!Es ist einfach unmöglich, beides zu verwalten, da Sie Ihre Bytes erst ordnen können, wenn Sie eine weitere Kopie eines verlorenen Pakets erhalten. Das ist der Hauptkompromiss.

Führen Sie einen RDP-Multicast durch.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow