Découverte du serveur UDP - Les clients doivent-ils envoyer des multidiffusions pour trouver le serveur ou le serveur doit-il envoyer une balise régulière?

Question

J'ai des clients qui ont besoin de se connecter à un seul processus serveur. J'utilise la découverte UDP pour que les clients trouvent le serveur. J'ai le client et le serveur échangent l'adresse IP et le numéro de port, de sorte qu'une connexion de TCP/IP puisse être établie après accomplissement de la découverte. De cette façon, la taille des paquets est maintenue petite. Je vois que cela peut se faire de deux façons en utilisant UDP:

1. Chaque client envoie son propre message de multidiffusion à la recherche du serveur auquel le serveur répond. Le client peut répéter l'envoi de ce message de multidiffusion à intervalles réguliers (dans le cas où le serveur est arrêté) jusqu'à ce que le serveur réponde.
2. Le serveur envoie une balise de multidiffusion à intervalles réguliers. Les clients s'abonnent au groupe de multidiffusion et reçoivent ainsi le message de multidiffusion du serveur et terminent la découverte.

Dans 1. s'il y a beaucoup de clients alors il y aurait initialement beaucoup de messages de multidiffusion transmis (un de chaque client). Seul le serveur s'abonne et reçoit les messages de multidiffusion des clients. Une fois que le serveur a répondu au client, le client cesse d'envoyer le message de multidiffusion. Une fois que tous les clients ont terminé leur découverte du serveur, aucun autre message de multidiffusion n'est transmis sur le réseau. Cependant, si le serveur est hors service, chaque client enverra une balise de multidiffusion jusqu'à ce que le serveur soit de retour et puisse répondre.

Dans 2. seul le serveur soumettrait une balise de multidiffusion à intervalles réguliers. Ce message finirait par être routé vers tous les clients abonnés au groupe de multidiffusion. Une fois que les clients ont reçu le paquet, la prise d'écoute UDP du client est fermée et ils ne sont plus abonnés au groupe de multidiffusion. Cependant, le serveur doit continuer à envoyer la balise de multidiffusion, afin que les nouveaux clients puissent le découvrir. Il continuerait à envoyer la balise à intervalles réguliers, que les clients ne soient pas obligés de faire une découverte ou non. Donc, je vois les avantages et les inconvénients de toute façon. Il me semble que le n ° 1 entraînerait une charge plus lourde au départ, mais cette charge finit par diminuer jusqu'à zéro. Dans # 2 le serveur continuerait à envoyer une balise pour toujours.

UDP et multicast est un sujet relativement nouveau pour moi, donc je suis intéressé à trouver quelle serait l'approche préférée et qui se traduirait par moins de charge réseau.

Answer 1

Je recommanderais la méthode n ° 2, car il est probable (selon l'application) que vous aurez beaucoup plus de clients que de serveurs. En envoyant une balise au serveur, vous n'envoyez qu'un seul paquet de temps en temps, plutôt qu'un paquet par client.

L'autre avantage de cette méthode est qu'elle permet aux clients de déterminer plus facilement quand un nouveau serveur devient disponible ou lorsqu'un serveur existant quitte le réseau, car ils n'ont pas besoin de maintenir une connexion à chaque serveur. serveur, ou continuer à interroger chaque serveur, pour le savoir.

Answer 2

Les deux sont des méthodes également viables.

L'argument pour la méthode n ° 1 serait que, en principe, les clients lancent des requêtes, et les serveurs les écoutent et y répondent. L'argument pour la méthode n ° 2 serait que le point de multidiffusion est de sorte qu'un hôte puisse envoyer un paquet et qu'il puisse être reçu par de nombreux clients (un-à-plusieurs), donc il est censé être l'inverse de #1.OK, comme je pense à ce sujet, je suis actuellement attiré par # 2, balise initiée par le serveur. Le problème aveC# 1 est que disons que les clients diffusent des balises, et qu'ils se connectent avec le serveur, mais le serveur se déconnecte ou change d'adresse IP. Lorsque le serveur est de sauvegarde et envoie sa première balise, tous les clients seront notifiés en même temps pour se reconnecter, et votre système entier est immédiatement sauvegardé. AveC# 1, tous les clients devraient se rendre compte individuellement que le serveur est parti, et ils commenceraient tous la multidiffusion en même temps, jusqu'à ce qu'ils se connectent de nouveau avec le serveur. Si vous aviez 1000 clients et 1 serveur, votre charge réseau serait littéralement 1000 fois supérieure à la méthode n ° 2.

Je sais que ces messages sont très probablement petits, et 1000 paquets à la fois ne sont rien à un réseau UDP, mais seulement d'un point de vue de design # 2 se sent mieux. Je sens que je suis en train de développer un trouble de la personnalité divisée ici, mais je pensais à un point puissant de la raison pour laquelle # 1 serait un avantage ... Si vous avez déjà voulu mettre en place une sorte de naturel équilibrage de charge ou mise à l'échelle avec plusieurs serveurs, la conception n ° 1 fonctionne bien pour cela. De cette façon, le premier serveur "disponible" peut répondre à la balise du client et s'y connecter, par opposition à # 2 où tous les clients accèdent au serveur de balisage.

Answer 3

Votre option # 2 a une grande limite en ce sens qu'elle suppose que le serveur peut communiquer plus ou moins directement avec tous les clients possibles. Selon l'architecture réseau exacte de votre système opérationnel, cela peut ne pas être le cas. Par exemple, vous pouvez être certain que tous les routeurs, les logiciels VPN, les réseaux étendus et les NAT, et tout ce qui relie les réseaux, peuvent gérer les paquets de balises de multidiffusion. AveC# 1, vous supposez que les clients peuvent envoyer un paquet UDP au serveur. C'est une attente tout à fait raisonnable, d'autant plus que la prochaine chose que le client fera est de faire une connexion TCP au même serveur.

Si le serveur tombe en panne et que le client veut savoir quand il est de retour, soyez sûr à utiliser exponential backoff sinon vous prendrez le réseau vers le bas avec une tempête de paquets un jour!

Answer 4

J'ai utilisé l'option 2 plusieurs fois auparavant. Cela fonctionne bien pour les topologies réseau simples. Nous avons constaté des problèmes de débit lorsque les datagrammes UDP dépassaient le MTU Ethernet, ce qui entraînait une grande fragmentation. Le plus gros problème que nous avons vu est que la découverte de multidiffusion se décompose en topologies plus grandes puisque de nombreux routeurs sont configurés pour bloquer le trafic de multidiffusion.

Le issue that Greg alluded to est plutôt important à prendre en compte lors de la conception de votre suite de protocoles. Dès que vous allez au-delà des simples topologies de réseau, vous devrez trouver des solutions pour address translation, IP spoofing, et toute une série d'autres problèmes liés au transfert de votre couche de découverte vers votre couche de communication. La plupart d'entre eux doivent faire spécifiquement avec la façon dont votre serveur s'identifie et s'assurer que l'identification est quelque chose qu'un client peut utiliser. Si je pouvais le faire à nouveau (combien de fois avons-nous prononcé cette phrase), je chercherais des mécanismes de découverte basés sur les standards qui correspondent à la facture et commenceraient à résoudre les autres problèmes de la suite de protocoles. La dernière chose que vous voulez vraiment faire est de trouver un très bon système de découverte qui casse la semaine après le déploiement à cause d'une topologie de réseau imprévue. Google service discovery pour une liste de départ. Personnellement, je tends vers DNS-SD mais il y a beaucoup d'autres options disponibles.