Peer to Peer: méthodes de recherche de pairs

Question

Existe-t-il des méthodes connues pour rechercher des pairs 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 à chaque fois une nouvelle adresse IP, et que je souhaite me connecter sans configurer de serveur dédié pour s'enregistrer.

Je pensais à utiliser l'adresse électronique de vos pairs pour envoyer périodiquement un manifeste de pairs connectés, avec une sorte de code temporel, éliminant ainsi le besoin d'un serveur dédié. Ce serait une solution de rechange si aucun des homologues ne pouvait être connecté après avoir essayé toutes les adresses homologues connues auparavant. Mais les modèles existants de recherche de pairs seraient préférables.

Answer 1

Il n’est pas inutile de connaître au moins un pair initial pour en découvrir 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 le fait que chaque client possède une liste de démarrage de quelques pairs. Celles-ci peuvent provenir d'un traqueur automatisé basé sur le Web, par exemple. Le client découvre tout ou partie du réseau en demandant plus d'adresses à d'autres pairs, par exemple lors de la délégation d'une recherche de fichier.

Si vous ne pouvez réellement disposer d'aucune sorte de ressource centralisée, le mieux que vous puissiez faire est de trouver le premier homologue par le biais de messages diffusés et, finalement, de l'analyse des adresses IP. La première approche est bien intentionnée mais dans au moins 98% des cas, elle ne donne aucun résultat. Bien entendu, cette dernière approche consiste à utiliser Internet de manière abusive et illégale dans la plupart des pays.

Je penserais 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 bloqué par dix-vingt scripts de ce type, hébergés par des personnes qui ne se connaissent même pas). Et cela est certainement plus léger que le courrier électronique (qui, à cause des filtres anti-spam, ne fonctionnerait de toute façon pas).

Answer 2

Dans le cas limité de pairs au sein d'un intranet, il est possible d'envoyer un message UDP en diffusion à un port connu en demandant aux pairs de faire un rapport.

Answer 3

Profitez de tout forum existant où les données peuvent être publiées. Pensez au canal IRC secret, en incorporant des données dans des photos et en les publiant sur des sites de partage de photos 4chan ?, tout site permettant à votre application de se connecter et de publier des données sans login captia, etc.

http://chatzilla.hacksrus.com/faq/#password

Une autre stratégie pourrait consister à incorporer des messages dans des transactions en devise numérique. Choisissez une pièce bon marché qui risque de traîner ... Une pièce DOGE ou MOON peut-être. Créez des fonctionnalités de portefeuille dans votre application. de sorte que vous puissiez enregistrer des micro-transactions 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 penny. Même s'ils interdisent ultérieurement l'ajout de métadonnées aux transactions, vous pouvez effectuer une transaction équivalente à votre adresse IP dans MOON et utiliser des adresses fantômes dans la pièce MOON pour votre application. de telle sorte que lorsqu'un nouveau nœud se connecte, il sait quoi rechercher dans la chaîne de chaînes - 2daMOON% bootStr @ pM3. ENVOYER - 104.003021133 MOON IP = 104.3.21.133 proposition pas chère.

Answer 4

Le client BitcoinQT utilise diverses méthodes pour rechercher des nœuds. Certaines d'entre elles peuvent vous être utiles.

Découverte du nœud client Satoshi

IRC n'est plus utilisé, mais pourrait être le plus facile à implémenter:

  

À partir de la version 0.6.x, le client Bitcoin n'utilise plus l'amorçage IRC par défaut et, à partir de la version 0.8.2, la prise en charge de l'amorçage IRC a été complètement supprimée. La documentation ci-dessous est exacte pour la plupart des versions précédentes.

     

En plus d'apprendre et de partager sa propre adresse, le nœud a appris l'existence 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 pseudonyme. Ensuite, il a rejoint de manière aléatoire un canal IRC nommé entre # bitcoin00 et # bitcoin99. Ensuite, il a émis une commande de l'OMS. Le fil a lu les lignes telles qu'elles sont apparues dans le canal et a décodé les adresses IP des autres nœuds du canal. Il l'a fait en boucle, à tout jamais, jusqu'à ce que le nœud soit arrêté.

     

Lorsque le client a découvert une adresse d'IRC, il a réglé l'horodatage de l'adresse sur 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.

Answer 5

Trois façons différentes, même si vous aurez toujours besoin d’un serveur central pour établir la connexion, sauf si vous utilisez l’option 3.

• Serveur central conservant une liste connue de pairs, avec Keep-Alive.
• Un ou plusieurs serveurs centraux qui gèrent certaines ressources communes peuvent se découvrir, mais une fois connectés, ils n'ont plus besoin du serveur central tant que l'homologue reste connecté (comme BitTorrent). peut également chaîner des connexions peering.
• Analyse du port / IP ( fortement déconseillé ).

Dans votre exemple, vous disposeriez toujours d’une sorte de serveur central sur lequel les pairs seraient enregistrés; le protocole est la seule différence.

Answer 6

Vieille question, mais je réfléchissais moi-même à ce problème, je vais donc ajouter 2 centimes. En bref, un serveur central n'est pas nécessaire si un nœud est informé d'au moins un homologue valide. Les nouveaux nœuds doivent être ajoutés au réseau par tout membre actuel (par exemple, invité ou un nœud génère un autre nœud, en fonction de votre application).

En supposant 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épendront de la nature du système; par exemple. combien de temps les pairs restent-ils connectés, s'ils utilisent des adresses stables

• les agents partagent les informations entre homologues avec d'autres homologues

• au moins certains agents restent disponibles pendant relativement longtemps par rapport au nœud de fréquence qui se connecte au réseau pour mettre à jour son carnet d'adresses (ou les nœuds ont des adresses stables)

• en plus des adresses homologues, les informations de disponibilité sont également suivies (de nombreuses options dépendent de votre système. Les exemples incluent: si l'homologue a une adresse stable, lors de la dernière consultation, certaines métriques de disponibilité, informations de type contenu / service, adresse valide jusqu'à l'heure si elle est connue)

• les nouveaux agents sont initialisés avec au moins un homologue valide (ne doit pas nécessairement être un nœud central, il peut s'agir de tout nœud valide)

Des

• mécanismes de confiance seront nécessaires si des homologues malveillants sont une possibilité

Lorsqu'un homologue entre en ligne, il interroge les homologues de sa table d'homologues pour déterminer ceux qui sont actifs et peut-être supprime les adresses dynamiques expirées. Les nœuds échangent des informations entre pairs et peuvent devenir eux-mêmes liés Cette découverte / cet échange entre homologues peut se poursuivre pendant un certain nombre de sauts ou via une marche aléatoire jusqu’à la liste des homologues si sa taille et / ou sa qualité est suffisante.

Quelques détails supplémentaires:

• Les nœuds se connectent et partagent les informations sur les homologues avec une fréquence liée à la fréquence de changement d'adresse, pour éviter que le carnet d'adresses ne devienne obsolète et que le nœud ne soit déconnecté 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 acceptés, afin d'éviter une tendance à la centralisation autour des nœuds les plus stables.

• Les nœuds doivent être sélectifs quant aux pairs qu’ils gardent. c'est-à-dire ceux dans lesquels ils sont plus susceptibles d'échanger des données (par exemple, un poids basé sur l'historique)

• Les liens de nœud peuvent être asymétriques ou symétriques en fonction de l'application

Answer 7

Pour le dire simplement non, il n'y a aucun moyen de faire cela sans un serveur central.

Si vous voulez faire cela, vous avez simplement besoin d’un ou de 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 le seul moyen véritablement judicieux de le faire est avec votre propre serveur. Dans le scénario le plus simple, il suffit d’envoyer une adresse IP en réponse.

Des séparations virtuelles peuvent être effectuées pour environ 15 $ / mois, ce que l’OMI coûte beaucoup moins cher que d’utiliser ou d’abuser de la bande passante de quelqu'un d’autre.

[Modifier].

Pour le dire simplement, il existe un autre moyen, comme suit.

Après réflexion, je pense que ce que je ferais, c’est de désigner un ensemble d’homologues comme contrôleurs de cluster et d’utiliser un service DNS dynamique pour permettre à d’autres homologues de découvrir les contrôleurs de cluster.

Choisissez un fournisseur DNS dynamique que je nommerai myc.ath.cx (j'utilise http: // www. dyndns.com/ ).

Chaque pair doit être capable de devenir un contrôleur de cluster. Un contrôleur de cluster contiendra une liste de tous les autres pairs connectés.

Quand un pair est démarré, il cherche myc.ath.cx et tente de se connecter. Si la connexion ne peut pas être établie dans un délai, disons 30 secondes, l’enregistrement de l’entrée DNS est pris en charge.

Tout pair souhaitant découvrir d'autres pairs peut simplement interroger myc.ath.cx et une liste lui sera fournie

Tous les homologues sont chargés de télécharger périodiquement la liste des homologues, au cas où ils auraient besoin d'un contrôleur de cluster.

Le contrôleur de cluster interroge périodiquement l'entrée DNS. S'il a changé d'adresse IP, il sait qu'il n'est plus le contrôleur de cluster. Il contacte donc le contrôleur de cluster disposant de l'entrée DNS et lui fournit la liste suivante. hôtes connus.

Le contrôleur de cluster contactera périodiquement les hôtes de la liste pour s'assurer qu'ils sont toujours valides.

Answer 8

Votre méthode d'envoi d'e-mail utilise un serveur dédié, cependant; 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 la messagerie électronique utilise, bien que de manière oblique) SAUF si vous êtes en mesure de caractériser la connectivité à Internet utilisée par vos pairs.

Fondamentalement, si vous avez un nombre de pairs X, qui se connectent pendant une durée Y, puis qu’ils sont hors de la grille pendant une durée Z ... essentiellement, vous pouvez construire une équation de probabilité de la probabilité c’est que le groupe de pairs que vous avez contacté en dernier est toujours disponible; Lorsque cette probabilité approche 1 (pour un ensemble donné de X, Y et Z ci-dessus), vous pouvez probablement gérer 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 simple service gratuit en ligne pour spécifier une liste de pairs. Mettre en place un groupe yahoo, ou quelque chose comme ça; les clients peuvent automatiquement le rechercher et obtenir une adresse de pair à partir de laquelle interroger un ensemble de pairs le client peut être codé avec l’authentification pour publier dans le groupe, et peut publier périodiquement son adresse IP afin que les autres utilisateurs puissent demander l’ensemble des homologues actifs connus.

Si vous voulez être vraiment compliqué, vous pouvez commencer à utiliser des méthodes fondamentalement stéganographiques pour masquer les informations de localisation des homologues. C'est à dire. obtenir une recherche google pour "blah" ;; trouvez le premier site répertorié dans les résultats qui possède un tableau de messages non protégé (pas de CAPTCHA); trouvez le troisième message (ou un autre message) commençant par "Indubitablement" (ou peu importe), et trouvez l'en-tête du premier message à cet endroit, et il y a l'adresse IP d'un homologue. Si cela ne fonctionne pas, passez à la liste suivante avec les termes de recherche.

Mais c'est sournois. : -)

Answer 9

Pourriez-vous réutiliser un serveur dédié existant à cette fin?

Je pense en particulier à enregistrer chacun des pairs avec un DNS dynamique, mais si vous êtes prêt à être un peu plus laid, partagez l'accès à un compte Hotmail connu, à Google Doc ou à un site similaire.

Answer 10

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 indexer par Google, vous pouvez concevoir un système dans lequel chaque pair exploite un site Web avec des 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 du réseau formé, mais c’est à peu près le cas de tout réseau P2P dépourvu de tout mécanisme de sécurité.

L’astuce serait de faire en sorte que les sites Web soient analysés et hautement classés par Google (ou un autre moteur de recherche) en fonction de votre ensemble arcanique de termes de recherche. Je peux penser à plusieurs manières, mais ce ne sont pas celles que je voudrais utiliser. Pour un service légitime, je préférerais dépenser de l'argent ou trouver un site Web gratuit pouvant servir de répertoire.

Answer 11

Qu'en est-il d'un autre système P2P spécialement conçu pour suivre les homologues en ligne d'autres systèmes P2P?

Ensuite, nous réduisons le problème de la recherche de pairs pour tout nouveau système P2P, mais simplement de trouver des pairs pour le système "principal" P2P, qui vous donnera les adresses des pairs en ligne du système que vous souhaitez utiliser ...

Answer 12

Ceci est une utilisation typique d'un algorithme de table de hachage distribuée. Je suggère de regarder quelque chose comme une pâtisserie. Il utilise un réseau en superposition (réseau de couche application) au-dessus des autres couches.

Chaque nœud a un GUID utilisé pour acheminer les requêtes sur le réseau homologue.

Answer 13

Si vous êtes à la recherche d'un serveur central déjà établi, consultez l'entrée du métaserveur à la page:
http://martindevans.appspot.com/
Vous pouvez y inscrire des pairs, puis d'autres pairs peuvent les trouver. Évidemment, il s’agit d’un serveur central, mais il ne nécessite aucune maintenance de votre part.