Peer to Peer: Méthodes de recherche de pairs
Existe-t-il des méthodes connues pour trouver des homologues sans utiliser de serveur central dédié?
c'est-à-dire: si j'ai des pairs qui se déconnectent et se reconnectent à Internet mais obtiennent une nouvelle adresse IP à chaque fois, et que je veux me connecter sans configurer de serveur dédié pour s'inscrire.
Je pensais à utiliser l'adresse e-mail des pairs pour envoyer périodiquement un manifeste des pairs connectés, avec une sorte de code temporel, ce qui annulait le besoin d'un serveur dédié. Ce serait un repli si aucun des homologues ne pouvait être connecté après avoir essayé toutes les adresses d'homologues précédemment connues. Mais les modèles existants de recherche de pairs seraient préférables.
Il n'y a aucun moyen de connaître au moins un pair initial pour en savoir plus. Les protocoles entièrement P2P, tels que Gnutella ou Gnutella2, ou le plus simple Overnet (rendu célèbre par Storm Worm), sont basés sur chaque client ayant une liste de démarrage de quelques pairs. Ceux-ci peuvent sortir d'un tracker automatisé basé sur le Web par exemple. Le client découvrira l'ensemble du réseau ou des parties de celui-ci en demandant à d'autres homologues plus d'adresses, par exemple lors de la délégation d'une recherche de fichier.
Si vous ne pouvez vraiment pas avoir de ressource centralisée, le mieux que vous puissiez faire est de trouver le premier homologue à travers les messages diffusés et, finalement, le balayage des adresses IP. La première approche est bien intentionnée mais dans au moins 98% des cas, elle ne donnera aucun résultat. La dernière approche, bien sûr, est d'abuser d'Internet, ainsi qu'illégal dans la plupart des pays.
Je repenserais vraiment à avoir une sorte de tracker central. Cela peut être quelque chose d'aussi simple qu'un script PHP sur un serveur Web (le réseau gnutella, aujourd'hui, est soutenu par dix à vingt scripts de ce type, hébergés par des gens qui ne se connaissent même pas). Et cela est certainement plus léger que le courrier électronique (qui, en raison des filtres anti-spam à tout le moins, ne fonctionnerait pas de toute façon).
Dans le cas limité de pairs au sein d'un intranet, il est possible d'envoyer un message UDP de diffusion à un port connu pour demander aux pairs de faire rapport.
Profitez de tout forum existant où les données peuvent être publiées. Pensez secret IRC, intégrant des données dans les photos et publiant sur les sites de partage de photos 4chan?, Tout site qui permettrait à votre application de se connecter et de publier des données sans connexion captia, etc.
http://chatzilla.hacksrus.com/faq/#password
Une autre stratégie pourrait consister à intégrer des messages dans les transactions en monnaie numérique. Choisissez une pièce bon marché qui risque de traîner ... peut-être une pièce DOGE ou MOON. Intégrez une fonctionnalité de portefeuille à votre application. de sorte que vous pouvez poster des micro-transactions dans les deux sens entre les adresses contrôlées par votre application. Il y aurait toujours des frais pour les mineurs, mais ce ne sont que des fractions de centimes. Même s'ils interdisent ultérieurement d'ajouter des métadonnées aux transactions, vous pouvez effectuer une transaction équivalente à votre adresse IP dans MOON et utiliser des adresses personnalisées dans MOON coin pour votre application. de sorte que lorsqu'un nouveau nœud arrive en ligne, il sait quoi rechercher dans la chaîne de blocs - 2daMOON% bootStr @ pM3. ENVOYER - 104.003021133 MOON IP = 104.3.21.133 pas une proposition coûteuse.
Le client BitcoinQT utilise une variété de méthodes pour trouver des nœuds, certains d'entre eux peuvent vous être utiles.
Client Satoshi Node Découverte
L'IRC n'est plus utilisé, mais pourrait être le plus facile à implémenter:
Depuis la version 0.6.x, le client Bitcoin n'utilise plus IRC bootstrapping par défaut, et depuis la version 0.8.2 la prise en charge de IRC bootstrapping a été complètement supprimée) Cette documentation ci-dessous est exacte pour la plupart des versions antérieures.
En plus d'apprendre et de partager sa propre adresse, le nœud a découvert d'autres adresses de nœud via un canal IRC. Voir irc.cpp .
Après avoir appris sa propre adresse, un nœud a codé sa propre adresse dans une chaîne à utiliser comme surnom. Ensuite, il a rejoint au hasard un canal IRC nommé entre # bitcoin00 et # bitcoin99. Ensuite, il a émis une commande WHO. Le thread a lu les lignes telles qu'elles apparaissaient dans le canal et décodé les adresses IP des autres nœuds dans le canal. Il l'a fait en boucle, pour toujours, jusqu'à l'arrêt du nœud.
Lorsque le client a découvert une adresse à partir d'IRC, il a défini l'horodatage de l'adresse à l'heure actuelle, mais il a utilisé une "pénalité" de 51 minutes, ce qui signifie qu'il semblait avoir été vu presque une heure plus tôt.
Vieille question, mais j'ai pensé à ce problème moi-même, je vais donc ajouter mes 2 cents. En bref, un serveur central n'est pas requis si un nœud connaît au moins un homologue valide. De nouveaux nœuds doivent être ajoutés au réseau par n'importe quel membre actuel (par exemple, invité, ou le nœud génère un autre nœud, selon votre application).
En admettant que:
les agents gardent une trace de leurs pairs; la taille de ce carnet d'adresses et la manière dont les entrées sont gérées dépendent de la nature du système; par exemple. combien de temps les pairs restent connectés, si les pairs utilisent des adresses stables
les agents partagent des informations avec leurs pairs
au moins certains agents restent disponibles pendant des périodes relativement longues par rapport à la fréquence à laquelle le nœud se connecte au réseau pour mettre à jour son carnet d'adresses (ou les nœuds ont des adresses stables)
en plus des adresses d'homologue, les informations de disponibilité sont également suivies (de nombreuses options ici en fonction de votre système. Les exemples incluent: si l'homologue a une adresse stable, la dernière fois, une métrique de disponibilité, des informations sur le type de contenu/service, une adresse valide jusqu'à ce temps si connu)
les nouveaux agents sont initialisés avec au moins un homologue valide (ne doit pas nécessairement être un nœud central, peut être n'importe quel nœud valide)
des mécanismes de confiance sont nécessaires si des pairs malveillants sont une possibilité
Lorsqu'un homologue se connecte, il interroge les homologues de sa table d'homologues pour découvrir lesquels sont actifs et supprime peut-être les adresses dynamiques expirées. Les nœuds échangent des informations sur les pairs et peuvent devenir eux-mêmes liés. Cette découverte/échange de pairs peut continuer un certain nombre de sauts ou via une marche aléatoire jusqu'à la liste de pairs si elle est de taille et/ou de qualité suffisante.
Quelques détails supplémentaires:
Les nœuds se connectent et partagent des informations sur les homologues avec une fréquence liée à la fréquence à laquelle les adresses des nœuds changent, de sorte que le carnet d'adresses ne devient pas périmé et que le nœud se déconnecte car aucun de ses anciens homologues n'est disponible à leurs dernières adresses connues
Les nœuds peuvent avoir besoin de limiter le nombre de pairs qu'ils acceptent, pour éviter la tendance à la centralisation autour des nœuds les plus stables.
Les nœuds doivent être sélectifs sur les pairs qu'ils gardent; c'est-à-dire ceux dans lesquels ils sont plus susceptibles d'échanger des données (par exemple, poids basé sur l'historique)
Les liaisons de nœuds peuvent être asymétriques ou symétriques selon l'application
Trois façons, du haut de ma tête, bien que vous ayez toujours besoin d'un serveur central pour démarrer la connexion, sauf si vous avez opté pour l'option 3.
- Serveur central qui maintient la liste connue des pairs, avec maintien en vie.
- Un ou plusieurs serveurs centraux qui maintiennent des pairs de ressources communs peuvent utiliser pour se découvrir, mais une fois connectés, ils n'ont plus besoin du serveur central tant que le pair reste connecté (quelque chose comme BitTorrent); peut également chaîner des connexions homologues.
- Numérisation Port/IP (fortement déconseillé).
Dans votre exemple, vous auriez toujours une sorte de serveur central où les pairs seraient enregistrés; le protocole est la seule différence.
Pour le dire simplement non, il n'y a aucun moyen de le faire sans un serveur central.
Si vous voulez faire cela, vous avez simplement besoin d'un ou plusieurs serveurs centraux, que ce soit par DNS dynamique ou non. Les clients ont besoin d'une méthode pour découvrir où ils doivent se connecter, et la seule façon vraiment raisonnable de le faire est avec votre propre serveur, dans le scénario le plus simple, il n'a qu'à envoyer une adresse IP en réponse.
Les serveurs virtuels peuvent être achetés pour environ 15 $/mois, ce qui est considérablement moins cher pour l'OMI que d'essayer d'utiliser ou d'abuser de la bande passante de quelqu'un d'autre.
[Éditer].
Pour le dire simplement, il existe une autre façon, comme suit.
Après réflexion, je pense que je ferais pour désigner un ensemble de pairs comme contrôleurs de cluster et utiliser un service DNS dynamique pour permettre à d'autres pairs de découvrir les contrôleurs de cluster.
Choisissez un fournisseur DNS dynamique, je l'appellerai myc.ath.cx (j'utilise http://www.dyndns.com/ ).
Chaque homologue doit être capable de devenir contrôleur de cluster. Un contrôleur de cluster contiendra une liste de tous les autres pairs connectés.
Lorsqu'un pair est démarré, il recherche myc.ath.cx et tente de se connecter. Si la connexion ne peut pas être établie dans un délai, disons 30 secondes, elle prend en charge l'enregistrement de l'entrée DNS.
Tout pair souhaitant découvrir d'autres pairs peut simplement interroger myc.ath.cx et une liste sera fournie
Tous les pairs sont responsables de télécharger périodiquement la liste des pairs, au cas où ils auraient besoin de mettre en cluster le contrôleur.
Le contrôleur de cluster interrogera périodiquement l'entrée DNS - s'il a changé de son adresse IP, il sait qu'il n'est plus le contrôleur de cluster - il contactera donc le contrôleur de cluster qui a actuellement l'entrée DNS et fournira sa liste d'hôtes connus.
Le contrôleur de cluster contacte périodiquement les hôtes de la liste pour s'assurer qu'ils sont toujours valides.
Qu'en est-il d'un autre système P2P conçu spécifiquement pour suivre les pairs en ligne d'autres systèmes P2P?
Ensuite, nous réduisons le problème de trouver des homologues pour tout nouveau système P2P à simplement trouver des homologues pour le système P2P `` principal '', ce qui vous donnera les adresses des homologues en ligne pour le système que vous souhaitez utiliser ...
Cependant, votre méthode d'envoi d'e-mails utilise un serveur dédié; le serveur de messagerie du pair, pour être précis.
En gros, je ne pense pas que ce soit possible sans utiliser une sorte de stockage ou de serveur dédié (ce que l'approche de messagerie fait, bien qu'obliquement) À MOINS que vous ne puissiez caractériser la connectivité à Internet que vos pairs utilisent.
Fondamentalement, si vous avez un ensemble de X pairs, qui se connectent pendant une durée Y, et qu'ils sont ensuite déconnectés de la grille pendant une durée Z ... essentiellement, vous pouvez construire une équation de probabilité sur la probabilité que l'ensemble des pairs que vous avez contactés pour la dernière fois est toujours disponible; lorsque cette probabilité approche 1 (pour un ensemble donné de X, Y et Z ci-dessus), vous pouvez très probablement maintenir un réseau d'égal à égal sans utiliser de stockage.
Peut-être plus dans l'esprit; au lieu d'avoir un "serveur central dédié", utilisez un service gratuit en ligne simple pour spécifier une liste de pairs. Mettre en place un groupe Yahoo, ou quelque chose comme ça; les clients peuvent le rechercher automatiquement et obtenir une adresse d'homologue à partir de laquelle interroger un ensemble d'homologues; le client peut être codé avec l'authentification pour publier dans le groupe et peut publier périodiquement son adresse IP afin que d'autres puissent demander l'ensemble des homologues actifs connus.
Si vous voulez devenir vraiment délicat, vous pouvez commencer à utiliser des méthodes essentiellement stéganographiques pour masquer les informations de localisation des pairs. C'est à dire. obtenir une recherche google pour "blah"; trouver le premier site répertorié dans les résultats qui a un babillard non protégé (pas de CAPTCHA); trouver le troisième (ou autre) post qui commence par "Indubitablement" (ou autre), et y trouver l'en-tête du premier message, et il y a l'adresse IP d'un homologue. Si cela ne fonctionne pas, descendez la liste des termes de recherche jusqu'au suivant.
Mais c'est sournois. :-)
Pourriez-vous réutiliser un serveur dédié existant à cet effet?
Je pense en particulier à enregistrer chacun des pairs avec un DNS dynamique, mais si vous vouliez devenir un peu plus laid, partager l'accès à un compte Hotmail connu ou à Google Doc ou similaire.
Vous pouvez utiliser un répertoire central ou une sorte de protocole de diffusion pour la découverte de services. En supposant que vous puissiez les faire indexer par Google, vous pourriez concevoir un système par lequel chaque pair gère un site Web avec quelques mots uniques et rares contenus sur une page spécifique. Vous pouvez ensuite utiliser les résultats de recherche Google basés sur ces mots pour identifier des pairs potentiels. Ce serait essentiellement une diffusion Internet (bruyante et lente).
Si la structure de la page était un modèle bien connu ou contenait des informations de connexion identifiables pour cet homologue, il serait facile de les distinguer dans les résultats de la recherche. L'utilisation d'un tel répertoire public vous laisse ouvert aux nœuds compromis dans le réseau formé, mais cela est à peu près vrai pour tout réseau P2P sans mécanisme de sécurité.
Faire en sorte que les sites Web soient explorés et hautement classés par Google (ou un autre moteur de recherche) pour votre ensemble mystérieux de termes de recherche serait l'astuce. Je peux penser à deux façons, mais ce ne sont pas celles que j'utiliserais. Pour un service légitime, je préfère dépenser de l'argent ou trouver un site Web gratuit qui pourrait fonctionner comme un annuaire.
Si vous recherchez un serveur central déjà établi, consultez l'entrée de métaserveur à la page ici:
http://martindevans.appspot.com/
Vous pouvez y inscrire des pairs, puis d'autres pairs peuvent les trouver. Il s'agit évidemment d'un serveur central, mais il ne nécessite aucune maintenance de votre part.
Il s'agit d'une utilisation typique d'un algorithme de table de hachage distribué. Je suggère de regarder quelque chose comme de la pâtisserie. Il utilise un réseau de superposition (réseau de couches d'application) au-dessus des autres couches.
Chaque nœud a un GUID qui est utilisé pour acheminer les demandes à travers le réseau homologue.