Peer to Peer: metodi di ricerca dei peer

https://stackoverflow.com/questions/310607

10-07-2019
|

Domanda

Esistono metodi noti per trovare i peer senza utilizzare un server centrale dedicato?

Ad esempio: se ho colleghi che si disconnettono e si riconnettono a Internet ma ottengono ogni volta un nuovo indirizzo IP e voglio collegarmi a loro senza configurare un server dedicato con cui registrarsi.

Stavo pensando di utilizzare l'indirizzo e-mail dei peer per inviare periodicamente un manifest di peer connessi, con una sorta di timecode, annullando la necessità di un server dedicato. Questo sarebbe un fallback se nessuno dei peer potesse essere collegato dopo aver provato tutti gli indirizzi peer precedentemente noti. Ma sarebbero preferibili modelli esistenti di ricerca di pari.

Soluzione

Non c'è modo di evitare di conoscere almeno un peer iniziale per scoprirne di più. I protocolli completamente P2P, come Gnutella o Gnutella2, o il più semplice Overnet (reso famoso da Storm Worm), si basano su ogni client con un elenco di avvio di alcuni peer. Questi possono venire fuori ad esempio da un tracker automatico basato sul web. Il client scoprirà l'intera rete o parti di essa chiedendo ad altri peer più indirizzi, ad esempio durante la delega di una ricerca di file.

Se davvero non puoi avere alcun tipo di risorsa centralizzata, la cosa migliore che puoi fare è trovare il primo peer attraverso i messaggi trasmessi e infine la scansione dell'indirizzo IP. Il primo approccio è ben intenzionato, ma in almeno il 98% dei casi non si otterrà alcun risultato. L'approccio successivo, ovviamente, sta abusando di Internet, oltre che illegale nella maggior parte dei paesi.

Ripenserei davvero ad avere una specie di tracker centrale. Può essere qualcosa di semplice come uno script PHP su un server web (la rete gnutella, oggi, è sostenuta da dieci venti di questi script, ospitati da persone che non si conoscono nemmeno). E questo è sicuramente più leggero dell'email (che, almeno per i filtri antispam, non funzionerebbe comunque).

Altri suggerimenti

Nel caso limitato dei peer all'interno di una rete Intranet, è possibile inviare un messaggio UDP broadcast a una porta nota chiedendo ai peer di riferire.

Approfitta di qualsiasi forum esistente in cui i dati possono essere pubblicati. Pensa al canale IRC segreto, incorporando i dati nelle foto e pubblicandoli nei siti di condivisione delle foto 4chan ?, qualsiasi sito che consentirebbe alla tua applicazione di accedere e pubblicare i dati senza accessi captia ecc.

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

Un'altra strategia potrebbe essere quella di incorporare i messaggi nelle transazioni in valuta digitale. Scegli una moneta a buon mercato che probabilmente rimarrà in giro ... DOGE o LUNA moneta forse. Crea funzionalità di portafoglio nella tua app. in modo tale da poter pubblicare micro transazioni avanti e indietro tra gli indirizzi controllati dalla tua app. Ci sarebbe ancora una tassa per i minatori, ma questa è solo una frazione di centesimi. Anche se in seguito vietassero l'aggiunta di metadati alle transazioni, potresti effettuare una transazione equivalente al tuo indirizzo IP in MOON e utilizzare indirizzi vanity in MOON coin per la tua app. tale che quando un nuovo nodo viene online sa cosa cercare nella blockchain - 2daMOON% bootStr @ pM3. INVIA - 104.003021133 IP MOON = 104.3.21.133 non è una proposta costosa.

Il client BitcoinQT utilizza una varietà di metodi per trovare nodi, alcuni dei quali potrebbero esserti utili.

Rilevazione nodo client Satoshi

IRC non è più utilizzato, ma potrebbe essere il più facile da implementare:

Dalla versione 0.6.x il client Bitcoin non utilizza più il bootstrap IRC per impostazione predefinita e dalla versione 0.8.2 il supporto per il bootstrap IRC è stato rimosso completamente. Questa documentazione di seguito è accurata per la maggior parte delle versioni precedenti.


Oltre ad apprendere e condividere il proprio indirizzo, il nodo ha appreso altri indirizzi di nodo tramite un canale IRC. Vedi irc.cpp .

Dopo aver appreso il proprio indirizzo, un nodo ha codificato il proprio indirizzo in una stringa da utilizzare come soprannome. Quindi, si è unito casualmente a un canale IRC chiamato tra # bitcoin00 e # bitcoin99. Quindi ha emesso un comando dell'OMS. Il thread ha letto le righe così come sono apparse nel canale e ha decodificato gli indirizzi IP di altri nodi nel canale. Lo ha fatto in un ciclo, per sempre, fino alla chiusura del nodo.

Quando il client ha scoperto un indirizzo da IRC, ha impostato il timestamp sull'indirizzo sull'ora corrente, ma ha usato una "penalità" di 51 minuti, il che significa che sembrava effettivamente visto quasi un'ora prima.

Tre modi, fuori dalla mia testa, anche se avrai sempre bisogno di un server centrale per avviare la connessione a meno che tu non sia andato con l'opzione 3.

Server centrale che mantiene un elenco noto di peer, con keep-alive.
Uno o più server centrali che mantengono alcuni peer di risorse comuni possono utilizzare per scoprirsi, ma una volta connessi non è più necessario il server centrale finché il peer rimane connesso (qualcosa come BitTorrent); può anche concatenare connessioni peer.
Scansione di porte / IP ( fortemente sconsigliato ).

Nel tuo esempio, avresti ancora una sorta di server centrale in cui i peer sarebbero registrati; il protocollo è l'unica differenza.

Vecchia domanda ma ho pensato a questo problema da solo, quindi pubblicherò i miei 2 centesimi. In breve, non è necessario un server centrale se un nodo è a conoscenza di almeno un peer valido. I nuovi nodi devono essere aggiunti alla rete da qualsiasi membro corrente (ad es. Invitato o il nodo genera un altro nodo, a seconda dell'applicazione).

Supponendo che:

tengono traccia dei colleghi; le dimensioni di questa rubrica e la modalità di gestione delle voci dipenderanno dalla natura del sistema; per esempio. per quanto tempo i peer rimangono connessi, se i peer usano indirizzi stabili
gli agenti condividono le informazioni sui peer con altri peer
almeno alcuni agenti rimangono disponibili per periodi relativamente lunghi rispetto al nodo di frequenza che si collega alla rete per aggiornare la sua rubrica (o i nodi hanno indirizzi stabili)
oltre agli indirizzi peer, vengono monitorate anche le informazioni sulla disponibilità (molte opzioni qui a seconda del sistema. Gli esempi includono: se il peer ha un indirizzo stabile, quando è stato visto l'ultima volta, alcune metriche di disponibilità, informazioni sul tipo di contenuto / servizio, indirizzo valido fino al momento, se noto)
i nuovi agenti sono inizializzati con almeno un peer valido (non deve essere un nodo centrale, può essere un nodo valido)
sono necessari meccanismi di fiducia se i peer dannosi sono una possibilità

Quando un peer è online, interroga i peer nella sua tabella peer per scoprire quali sono attivi e forse rimuove gli indirizzi dinamici scaduti. I nodi si scambiano informazioni tra pari e possono essere collegati da soli. Questa scoperta / scambio tra pari può continuare un certo numero di salti o tramite camminata casuale fino all'elenco dei pari se di dimensioni e / o qualità sufficienti.

Qualche dettaglio in più:

I nodi si connettono e condividono le informazioni dei peer con frequenza correlata alla frequenza con cui cambiano gli indirizzi dei nodi, quindi la rubrica non diventa stantia e il nodo viene disconnesso perché nessuno dei suoi peer precedenti è disponibile agli ultimi indirizzi noti
Potrebbe essere necessario che i nodi limitino il numero di peer che accettano, per evitare la tendenza alla centralizzazione attorno ai nodi più stabili.
I nodi dovrebbero essere selettivi sui peer che mantengono; vale a dire quelli in cui è più probabile che scambino dati (ad es. peso basato sulla storia)
I collegamenti ai nodi possono essere asimmetrici o simmetrici a seconda dell'applicazione

Per dirla semplicemente no, non c'è modo di farlo senza un server centrale.

Se vuoi farlo, hai semplicemente bisogno di uno o più server centrali, con DNS dinamico o meno. I clienti hanno bisogno di un metodo per scoprire dove dovrebbero connettersi e l'unico modo veramente sensato per farlo è con il proprio server, nello scenario più semplice deve solo inviare un indirizzo IP in risposta.

È possibile avere server virtuali per circa $ 15 al mese, il che IMO è notevolmente più economico rispetto al tentativo di utilizzare o abusare della larghezza di banda di qualcun altro.

[Modifica].

Per dirla semplicemente, c'è un altro modo, come segue.

Riflettendo, penso che ciò che farei è designare un set di peer come controller di cluster e utilizzare un servizio DNS dinamico per consentire ad altri peer di scoprire i controller di cluster.

Scegli un provider DNS dinamico che chiamerò myc.ath.cx (utilizzo http: // www. dyndns.com/ ).

Ogni peer deve essere in grado di diventare un controller di cluster. Un controller di cluster conterrà un elenco di tutti gli altri peer collegati.

Quando viene avviato un peer, cerca myc.ath.cx e tenta di connettersi. Se la connessione non può essere stabilita entro un periodo, diciamo 30 secondi, assume la registrazione della voce DNS.

Tutti i peer che desiderano scoprire altri peer possono semplicemente interrogare myc.ath.cx e verrà fornito un elenco

Tutti i peer sono responsabili del download periodico dell'elenco dei peer, nel caso in cui debbano essere controllati dal cluster.

Il controller del cluster interrogherà periodicamente la voce DNS - se è cambiato dal suo indirizzo IP, allora sa che non è più il controller del cluster - quindi contatterà il controller del cluster che attualmente ha la voce DNS e fornirà il suo elenco di host noti.

Il controller del cluster contatterà periodicamente gli host nell'elenco per assicurarsi che siano ancora validi.

Il tuo metodo di invio di e-mail utilizza tuttavia un server dedicato; il server di posta elettronica del peer, per essere precisi.

In parole povere, non penso che sia possibile senza usare una sorta di memoria o server dedicati (cosa che l'approccio e-mail fa, sebbene obliquamente) A MENO che non si sia in grado di caratterizzare la connettività a Internet che i tuoi colleghi stanno usando.

Fondamentalmente, se si dispone di un set di numero X di peer, che si connettono per Y per un periodo di tempo, e quindi sono fuori dalla griglia per Z per un periodo di tempo ... in sostanza, è possibile costruire un'equazione di probabilità sulla probabilità è che l'insieme di peer che hai contattato l'ultima volta è ancora disponibile; dove quella probabilità si avvicina a 1 (per un dato set di X, Y e Z sopra), molto probabilmente puoi sostenere una rete peer-to-peer senza usare l'archiviazione.

Forse più nello spirito; invece di avere un "server centrale dedicato", usa un semplice servizio online gratuito per specificare un elenco di pari. Crea un gruppo yahoo o qualcosa del genere; i client possono cercarlo automaticamente e ottenere un indirizzo peer dal quale interrogare un set di peer; il client può essere codificato con l'autenticazione per pubblicare nel gruppo e può pubblicare periodicamente il suo indirizzo IP in modo che altri possano richiedere il set di peer attivi noti.

Se vuoi diventare davvero complicato, puoi iniziare a usare metodi sostanzialmente steganografici per nascondere le informazioni sulla posizione dei pari. Cioè ottieni una ricerca su Google per " blah " ;; trova il primo sito elencato nei risultati che ha una bacheca non protetta (no CAPTCHA); trova il terzo (o qualunque altro) post che inizia con "indubbiamente" (o qualsiasi altra cosa) e trova l'intestazione del primo messaggio lì, e c'è l'indirizzo IP di un peer. Se il problema persiste, scorri l'elenco dei termini di ricerca al successivo.

Ma è subdolo. : -)

Potresti riutilizzare un server dedicato esistente allo scopo?

Sto pensando in particolare di registrare ciascuno dei peer con un DNS dinamico, ma se eri disposto a diventare un po 'più brutto, condividendo l'accesso a un account Hotmail noto o a Google Doc o simili.

È possibile utilizzare una directory centrale o una sorta di protocollo di trasmissione per il rilevamento del servizio. Supponendo che tu possa farli indicizzare da Google, potresti concepire un sistema in base al quale ogni peer gestisce un sito Web con alcune parole uniche e rare contenute in una pagina specifica. È quindi possibile utilizzare i risultati di ricerca di Google in base a queste parole per identificare potenziali peer. Questa sarebbe essenzialmente una trasmissione Internet (rumorosa e lenta).

Se la struttura della pagina fosse un modello ben noto o contenesse informazioni di connessione identificabili per quel peer, sarebbe facile distinguerle nei risultati della ricerca. L'uso di una tale directory pubblica ti lascia aperto ai nodi compromessi nella rete che si forma, ma questo è praticamente vero per qualsiasi rete P2P in assenza di un meccanismo di sicurezza.

Fare in modo che i siti web vengano sottoposti a scansione e classificati da Google (o da qualche altro motore di ricerca) per il tuo insieme arcano di termini di ricerca sarebbe il trucco. Posso pensare a un paio di modi, ma non sono quelli che vorrei usare. Per un servizio legittimo, preferirei spendere i soldi o trovare un sito web gratuito che potrebbe funzionare come una directory.

Che dire di un altro sistema P2P creato appositamente per tenere traccia dei peer online di altri sistemi P2P?

Quindi riduciamo il problema della ricerca di peer per qualsiasi nuovo sistema P2P alla semplice ricerca di peer per il sistema P2P "principale", che ti fornirà gli indirizzi dei peer online per il sistema che ti interessa usare ...

Questo è un uso tipico di un algoritmo di tabella hash distribuita. Suggerirei di guardare qualcosa come la pasticceria. Utilizza una rete overlay (rete a livello di applicazione) sopra altri livelli.

Ogni nodo ha un GUID che viene utilizzato per instradare le richieste attraverso la rete peer.

Se stai cercando un server centrale già stabilito, vedi la voce metaserver nella pagina qui:
http://martindevans.appspot.com/
È possibile registrare peer lì e quindi altri peer possono trovarli. Ovviamente questo è un server centrale, ma non richiede manutenzione da parte tua.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow