Une étude du protocole BitTorrent pour la coordination peer-to-peer distribué serait probablement un bon endroit pour commencer: http://www.bittorrent.org/beps/bep_0003.html
D'autres systèmes d'enquêter pourrait être le Tor distribué réseau d'anonymat, et le Windows Internet Name Service (WINS). Tout cela implique la découverte et la coordination des pairs dans une certaine mesure.
Probablement la partie la plus délicate de la mise en place d'un cluster P2P consiste à trouver un moyen fiable pour qu'un nouvel homologue découvre le cluster homologue. L'utilisation d'un numéro de port TCP prédéfini serait un début, mais s'effondre lorsque ce port est déjà utilisé par un autre processus. Vous pouvez utiliser une diffusion UDP pour savoir si des homologues sont présents, mais cela ne se répercutera pas sur votre premier saut de routeur car les routeurs filtrent généralement les diffusions pour éviter les tempêtes de propagation. Vous pouvez utiliser un tracker/dispatcher centralisé, mais cela devient un point de défaillance unique pour l'ensemble du cluster homologue.
La topologie du réseau affectera également votre approche de découverte. Si tous les pairs se trouvent dans le même segment de réseau, ou derrière le même pare-feu, vous pouvez faire à peu près n'importe quoi. Toutefois, si certains pare-feu se trouvent derrière un pare-feu, vous ne pouvez pas établir de connexion via le pare-feu: ils doivent vous établir une connexion ou ouvrir un port entrant dans le pare-feu en utilisant UPNP. La découverte est la partie la plus faible du système BitTorrent. À moins que l'utilisateur ne sache quel répertoire de torrent ou URL de suivi utiliser, le client torrent est inutile. Une fois que vous avez trouvé un nœud, n'importe quel nœud, dans un cluster d'homologues, trouve le reste des membres du cluster relativement simple.
Si votre ensemble de processus réside sur la même machine physique, vous pouvez utiliser quelque chose comme un service de file d'attente de messages pour agir en tant qu'arbitre tiers entre des processus transitoires. Sinon, vous envisagez probablement d'avoir l'un des processus du groupe de pairs en position de leadership pour répondre aux demandes de découverte et distribuer la liste des pairs aux autres. Lorsque le processus principal doit disparaître, il peut transmettre l'intérêt à l'un des autres homologues, ou les homologues peuvent basculer vers un nouveau processus pilote en utilisant la liste des homologues distribués. C'est essentiellement ce que fait le service de noms Windows (WINS) pour la découverte du nom NetBios.
Existe-t-il des moyens de simplifier le problème de la découverte du client lorsque vous savez que tous les homologues seront sur la machine locale? – Justin
Oui, sachant que tous les homologues sont sur la même machine réduit considérablement le problème posé, car vous n'avez pas à traiter avec les routeurs et les pare-feu et vous pouvez profiter des services de noms globaux OS non disponibles dans TCP/IP. Les tubes nommés sont point-à-point - ils ne peuvent pas avoir plusieurs écouteurs. – dthorpe
Votre meilleur pari est probablement d'utiliser la mémoire partagée nommée + mutex nommé avec des noms prédéfinis uniques de votre choix connu de tous les pairs. Utilisez cela pour la découverte de l'appartenance à un cluster.Un nouvel homologue rejoint le cluster en acquérant le mutex nommé, en lisant la liste des informations de connexion à partir de la zone de mémoire partagée, en écrivant ses propres informations de connexion à la fin de la liste et en libérant le mutex. Le nouveau pair dispose désormais d'un catalogue des membres du cluster. Certaines entrées peuvent être périmées, alors attendez-vous à des échecs de connexion. Mettre à jour la mémoire partagée périodiquement sous le mutex pour purger les entrées périmées. – dthorpe