Ich habe Clients, die alle mit einem einzelnen Serverprozess verbinden müssen. Ich verwende UDP-Erkennung für die Clients, um den Server zu finden. Ich habe den Client und den Server IP-Adresse und Port-Nummer austauschen, so dass eine TCP / IP-Verbindung nach Abschluss der Erkennung hergestellt werden kann. Auf diese Weise wird die Paketgröße klein gehalten. Ich sehe, dass dies auf zwei Arten mit UDP geschehen könnte:
In 1. Wenn es viele Clients gibt, dann würden anfangs viele Multicast-Nachrichten gesendet werden (eine von jedem Client). Nur der Server würde die Multicast-Nachrichten von den Clients abonnieren und empfangen. Sobald der Server auf den Client geantwortet hat, hört der Client auf, die Multicast-Nachricht zu senden. Sobald alle Clients ihre Entdeckung des Servers abgeschlossen haben, werden keine weiteren Multicast-Nachrichten über das Netzwerk übertragen. Wenn der Server jedoch nicht aktiv ist, sendet jeder Client eine Multicast-Nachricht in Intervallen aus, bis der Server wieder aktiv ist und antwortet.
In 2. nur der Server würde eine Multicast-Nachricht Beacon in regelmäßigen Abständen senden. Diese Nachricht würde am Ende an alle Clients weitergeleitet werden, die die Multicast-Gruppe abonniert haben. Sobald die Clients das Paket empfangen haben, wird der UDP-Abhörsocket des Clients geschlossen und sie sind nicht länger an der Multicast-Gruppe angemeldet. Der Server muss jedoch weiterhin das Multicast-Beacon senden, damit neue Clients es erkennen können. Es würde fortfahren, das Beacon in regelmäßigen Intervallen auszusenden, ungeachtet dessen, ob irgendwelche Clients nicht ihre Entdeckung erfordern oder nicht.
Also, ich sehe Pro und Contra so oder so. Es scheint mir, dass # 1 anfänglich zu einer stärkeren Belastung führen würde, aber diese Last reduziert sich schließlich auf Null. In # 2 würde der Server für immer einen Beacon senden.
UDP und Multicast sind ein ziemlich neues Thema für mich, deshalb bin ich daran interessiert herauszufinden, welcher der bevorzugte Ansatz wäre und was zu weniger Netzwerkbelastung führen würde.
Ich habe die Option # 2 in der Vergangenheit mehrmals benutzt. Es funktioniert gut für einfache Netztopologien. Es gab einige Durchsatzprobleme, wenn UDP-Datagramme die Ethernet-MTU überschritten, was zu einer großen Fragmentierung führte. Das größte Problem, das wir gesehen haben, ist, dass die Multicast-Erkennung in größeren Topologien zusammenbricht, da viele Router so konfiguriert sind, dass Multicast-Datenverkehr blockiert wird.
Die Adressübersetzung finden, IP-Spoofing und eine ganze Reihe anderer Probleme im Zusammenhang mit der Übergabe von Ihrer Discovery-Schicht an Ihre Kommunikationsschicht. Die meisten von ihnen haben speziell damit zu tun, wie sich Ihr Server identifiziert und sicherstellen, dass die Identifikation etwas ist, das ein Client nutzen kann.
Wenn ich es noch einmal machen könnte (wie oft haben wir diesen Satz ausgesprochen), würde ich nach standardbasierten Erkennungsmechanismen suchen, die auf die Rechnung passen und damit beginnen, die anderen Probleme der Protokollreihe zu lösen. Das letzte, was Sie wirklich tun möchten, ist ein wirklich gutes Erkennungsschema, das die Woche nach der Bereitstellung aufgrund einer unvorhergesehenen Netzwerktopologie durchbricht. Google service discovery für eine Startliste. Ich persönlich tendiere dazu, DNS-SD , aber es gibt eine Menge anderer Optionen.
Ich würde Methode # 2 empfehlen, da es wahrscheinlich ist (abhängig von der Anwendung), dass Sie weit mehr Clients als Server haben werden. Wenn der Server einen Beacon aussendet, senden Sie nur ein einziges Paket, anstatt nur ein Paket für jeden Client.
Der andere Vorteil dieser Methode besteht darin, dass die Clients leichter feststellen können, wann ein neuer Server verfügbar wird oder wann ein vorhandener Server das Netzwerk verlässt, da sie keine Verbindung zu jedem Server aufrechterhalten müssen , oder rufen Sie jeden Server ab, um es herauszufinden.
Beide sind gleichermaßen brauchbare Methoden.
Das Argument für Methode # 1 wäre, dass Clients im normalen Prinzip Anfragen initiieren und Server darauf hören und darauf reagieren.
Das Argument für Methode # 2 wäre, dass der Punkt von Multicast so ist, dass ein Host ein Paket senden kann und von vielen Clients (Eins-zu-Viele) empfangen werden kann, so dass es die Umkehrung von # ist. 1.
OK, wenn ich darüber nachdenke, bin ich von Server-initiiertem Beacon # 2 angezogen. Das Problem mit # 1 ist, dass Clients Beacons senden und sich mit dem Server verbinden, aber der Server entweder offline geht oder seine IP-Adresse ändert.
Wenn der Server wieder betriebsbereit ist und sein erstes Beacon sendet, werden alle Clients gleichzeitig benachrichtigt, um die Verbindung wiederherzustellen, und Ihr gesamtes System ist sofort wieder betriebsbereit. Mit # 1 müssten alle Clients einzeln erkennen, dass der Server verschwunden ist, und sie würden gleichzeitig mit dem Multicasting beginnen, bis sie wieder mit dem Server verbunden sind. Wenn Sie 1000 Clients und 1 Server hätten, wäre Ihre Netzwerklast buchstäblich 1000-mal größer als Methode 2.
Ich weiß, dass diese Nachrichten höchstwahrscheinlich klein sind, und 1000 Pakete gleichzeitig sind nichts für ein UDP-Netzwerk, aber nur vom Designstandpunkt aus fühlt sich # 2 besser an.
Edit: Ich fühle mich, als ob ich hier eine Spaltungspersönlichkeitsstörung entwickeln würde, aber dachte nur an einen kraftvollen Punkt, warum # 1 ein Vorteil wäre ... Wenn Sie jemals umsetzen wollten eine Art natürlicher Lastenausgleich oder Skalierung mit mehreren Servern, Design # 1 funktioniert gut dafür. Auf diese Weise kann der erste "verfügbare" Server auf das Beacon des Clients reagieren und sich mit ihm verbinden, im Gegensatz zu # 2, wo alle Clients zum Beaconing-Server springen.
Ihre Option # 2 hat eine große Einschränkung dahingehend, dass angenommen wird, dass der Server mehr oder weniger direkt mit jedem möglichen Client kommunizieren kann. Abhängig von der genauen Netzwerkarchitektur Ihres Betriebssystems ist dies möglicherweise nicht der Fall. Zum Beispiel können Sie davon abhängig sein, dass alle Router und VPN-Software sowie WANs und NATs und alle anderen Dinge, mit denen die Leute Netzwerke verbinden, tatsächlich mit Multicast-Beacon-Paketen umgehen können.
Mit # 1 gehen Sie davon aus, dass die Clients ein UDP-Paket an den Server senden können. Dies ist eine völlig vernünftige Erwartung, insbesondere wenn man bedenkt, dass der Client als nächstes eine TCP-Verbindung zum selben Server herstellt.
Wenn der Server ausfällt und der Client herausfinden will, wann er wieder da ist, sure um exponentieller Backoff sonst wirst du das Netzwerk irgendwann mit einem Paketsturm besiegen!