J'ai des clients qui doivent tous être connectés à un seul processus serveur. J'utilise la découverte UDP pour les clients pour trouver le serveur. J'ai l'adresse IP du client et du serveur Exchange et le numéro de port, de sorte qu'une connexion TCP / IP puisse être établie après la fin de la découverte. De cette façon, la taille du paquet est maintenue petite. Je vois que cela pourrait être fait de deux manières à l'aide de UDP:
in 1. S'il existe de nombreux clients, il y aurait à l'origine de nombreux messages de multidiffusion transmis (un de chaque client). Seul le serveur s'abonnerait et reçois 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. Si toutefois, le serveur est en panne, chaque client envoiait une balise de message de multidiffusion par intervalles jusqu'à ce que le serveur soit sauvegardé et puisse répondre.
in 2. Seul le serveur soumettrait une balise de message de multidiffusion à intervalles réguliers. Ce message finirait par se faire rouler à tous les clients qui sont souscrits au groupe de multidiffusion. Une fois que les clients reçoivent le paquet, la prise d'écoute UDP du client est fermée et elles ne sont plus abonnées au groupe de multidiffusion. Cependant, le serveur doit continuer à envoyer la balise de multidiffusion afin que de nouveaux clients puissent la découvrir. Il continuerait d'envoyer la balise à des intervalles réguliers, que les clients soient sur leur exigence de découverte ou non.
Alors, je vois des avantages et des inconvénients de toute façon. Il me semble que le n ° 1 entraînerait une charge plus lourde initialement, mais cette charge se réduit finalement à zéro. Dans # 2, le serveur continuerait à envoyer une balise pour toujours.
UDP et Multicast est un sujet assez nouveau pour moi. Je suis donc intéressé à déterminer qui serait l'approche préférée et qui entraînerait une charge moins réduite.
4 Réponses :
Je recommanderais la méthode n ° 2, telle qu'elle est probable (selon l'application) que vous aurez beaucoup plus de clients que vous les serveurs. En présentant le serveur envoyer une balise, vous n'envoyez qu'un paquet de chaque type, plutôt qu'un paquet pour chaque client.
L'autre avantage de cette méthode, c'est que cela facilite la détermination des clients lorsqu'un nouveau serveur devient disponible ou lorsqu'un serveur existant quitte le réseau, car ils ne doivent pas nécessairement gérer une connexion à chaque serveur. ou continuez à interroger chaque serveur, à découvrir.
Les deux sont des méthodes tout aussi viables.
L'argument de la méthode n ° 1 serait que, dans le principe normal, les clients initient des demandes et des serveurs écoutent et y répondent.
L'argument de 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 peut être reçu par de nombreux clients (un à plusieurs), il est donc censé être l'inverse de # 1.
OK, comme je pense à cela, je suis réellement dessiné à # 2, balise initiée par le serveur. Le problème avec n ° 1 est que, disons aux clients diffusons des balises, et ils raccrochent avec le serveur, mais le serveur devient hors ligne ou modifie son adresse IP.
Lorsque le serveur est sauvegardé et envoie sa première balise, tous les clients seront notifiés en même temps pour renouer, et votre système entier est de nouveau en hausse immédiatement. Avec N ° 1, tous les clients devraient se rendre compte de manière individuelle que le serveur est parti, et ils commenceraient tous la multidiffusion en même temps, jusqu'à ce que le dos soit connecté avec le serveur. Si vous aviez 1000 clients et 1 serveur, votre charge de réseau serait littéralement 1000 fois supérieure à la méthode n ° 2.
Je sais que ces messages sont probablement petits et 1 000 paquets à la fois ne sont rien sur un réseau UDP, mais juste à partir d'un point de vue de conception n ° 2 se sent mieux.
EDIT: Je sens que je développe un trouble de la personnalité de la scission ici, mais je pensais simplement qu'un point puissant de pourquoi # 1 serait un avantage ... Si jamais vous vouliez mettre en œuvre Une sorte d'équilibrage ou de mise à l'échelle de la charge naturelle 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 le connecter, par opposition au n ° 2 où tous les clients sautent sur le serveur de balises.
# 2: On pourrait ajouter un petit retard aléatoire à l'extrémité du client après la réception de la multidiffusion UDP avant de se connecter au serveur. Ensuite, tous les clients n'essaieraient pas de se connecter au serveur exactement au même moment. Assez d'entropie pour aléatoire (à des fins) pourrait être généré si les émissions UDP du serveur contiendraient un nombre aléatoire qui serait fusionné avec les adresses IP et MAC du client.
Votre option n ° 2 a une forte limitation en ce sens qu'elle suppose que le serveur peut communiquer plus ou moins directement avec chaque client possible. En fonction de l'architecture de réseau exacte de votre système opérationnel, cela peut ne pas être le cas. Par exemple, vous pouvez dépendre de tous les routeurs et logiciels VPN et WANS et NAT et toutes les autres choses que les gens connectent des réseaux avec, peuvent en réalité gérer les paquets de balise multidiffusion.
avec # 1, vous supposez que les clients puissent envoyer un paquet UDP sur le serveur. Il s'agit d'une attente tout à fait raisonnable, en particulier compte tenu de la chose la plus suivante que le client fera est de créer une connexion TCP au même serveur.
Si le serveur tombe en panne et que le client souhaite savoir quand il est sauvegardé, soyez sûr à utiliser Backoff exponentiel Sinon, vous prendrez le réseau avec une tempête de paquets un jour!
L'option n ° 1 est également basée sur l'envoi d'un paquet de multidiffusion, il vient d'aller dans la direction opposée - des mises en garde similaires s'appliquent.
Avec N ° 1, si le serveur tombe en panne, nous recevrons une pointe soudaine des messages de multidiffusion des clients. Cependant, seul le serveur serait souscrit au groupe de multidiffusion. Donc, si je comprends cela correctement, le routeur achèterait tous les messages à un seul point de fin (le serveur). Avec # 2, vous auriez pu avoir plus de 100 clients souscrit à la multidiffusion du serveur et que le routeur achèverait plus de 100 messages à chacun des points de fin du client. La charge de réseau ne serait-elle pas la même dans les deux cas? Réception de plus de 100 paquets arrivant en même temps sur le serveur (n ° 2) est une préoccupation? Cela se réduit progressivement à 0.
Correction: En fait, avec n ° 1, les paquets clients n'arriveraient pas tous en même temps sur les routeurs et le serveur. Le client a chacun des temps de démarrage différents. La balise client pourrait transmettre en disons dans des intervalles de 30 secondes. Chaque paquet est peut-être 200 octets de taille. Même avec 1000 paquets n'aurions-nous pas beaucoup de temps (ordinateur) pour les routeurs et le serveur de traiter? Le client pourrait également ralentir la balise s'il y a trop de tentatives infructueuses.
J'ai utilisé l'option n ° 2 au cours du passé plusieurs fois. Cela fonctionne bien pour de simples topologies de réseau. Nous avons connu des problèmes de débit lorsque les datagrammes UDP ont dépassé le MTU Ethernet, ce qui entraîne une grande fragmentation. Le plus grand problème que nous avons vu est que la découverte de multidiffusion tombe dans des topologies plus importantes puisque de nombreux routeurs sont configurés pour bloquer le trafic de multidiffusion.
Le Étant donné que Greg faisait allusion à est plutôt important à prendre en compte lorsque vous concevez votre suite de protocoles. Dès que vous vous déplacez au-delà de simples topologies de réseau, vous devrez trouver des solutions pour Traduction de l'adresse , Spoofing IP et une multitude d'autres problèmes liés au transfert de votre couche de découverte à votre couche de communication. La plupart d'entre eux doivent faire spécifiquement comment votre serveur s'identifie et veiller à ce que l'identification soit quelque chose qu'un client puisse utiliser.
Si je pouvais le faire à nouveau (combien de fois avons-nous prononcé cette phrase), je rechercherais des mécanismes de découverte basés sur des normes qui correspondent à la facture et commencent à résoudre les autres problèmes de suites de protocole. La dernière chose que vous voulez vraiment faire est de créer un très bon projet de découverte qui brise la semaine après votre déploiement à cause d'une topologie de réseau imprévue. Google Discovery de service pour une liste de départ. J'ai personnellement tendance vers DNS-SD mais il y a beaucoup d'autres options disponibles.
C'est une information très utile. Je développe un produit en C # qui sera déployé aux clients. Inutile de dire que les configurations de réseau et de routeur pourraient varier considérablement d'un site à l'autre. Un service client sera exécuté sur les postes de travail utilisateur et un hôte de serveur unique. WCF sera utilisé pour des messages normaux. DNS-SD est une proposition intéressante, j'ai besoin d'examiner cela un peu plus. J'ai trouvé un article intéressant: smallegan.com/blog/?p=28
Avez-vous explicitement décidé de ne pas utiliser les mécanismes de découverte de services standard?
Lorsque vous dites des mécanismes de découverte de service standard, pourriez-vous clarifier ce que vous considérez cela. Je suis en train de "découvrir" quelles sont mes options et la meilleure approche à prendre.
Cela n'a aucun sens pour le client d'envoyer des multidits, sauf si vous avez une grande forêt de serveurs. Le serveur doit envoyer les multidiffusions et les clients doivent les écouter.