Peer to Peer: Métodos para encontrar pares


¿Hay algún método conocido para encontrar pares sin usar un servidor central dedicado?

Es decir: Si tengo compañeros que son de desconectar y volver a conectar a internet, pero obtener una nueva dirección IP cada vez, y quiero conectarme a ellos, sin necesidad de configurar un servidor dedicado para registrarse.

Estaba pensando en usar la dirección de correo electrónico de los pares para enviar un manifiesto de pares conectados periódicamente, con algún tipo de código de tiempo, negando la necesidad de un servidor dedicado. Este sería una alternativa si ninguno de los pares pudiera conectarse después de probar todas las direcciones de pares previamente conocidas. Pero los modelos existentes de búsqueda de pares serían preferibles.

 48
p2p
Author: Robert Harvey, 2008-11-22

13 answers

No hay manera de evitar tener que conocer al menos un par inicial para descubrir más. Los protocolos totalmente P2P, como Gnutella o Gnutella2, o el más simple Overnet (hecho famoso por Storm Worm), se basan en que cada cliente tenga una lista de inicio de unos pocos pares. Estos pueden provenir de un rastreador automatizado basado en la web, por ejemplo. El cliente descubrirá toda la red o partes de ella pidiendo a otros pares más direcciones, por ejemplo, al delegar una búsqueda de archivos.

Si realmente no puedes tener cualquier tipo de recurso centralizado, lo mejor que puede hacer es encontrar el primer par a través de mensajes transmitidos y, en última instancia, el escaneo de direcciones IP. El primer enfoque es bien intencionado, pero en al menos el 98% de los casos no dará ningún resultado. El enfoque posterior, por supuesto, es el abuso de Internet, así como ilegal en la mayoría de los países.

Realmente me replantearía tener algún tipo de rastreador central. Puede ser algo tan simple como un script PHP en un servidor web (la red gnutella, hoy, se celebra por diez-veinte tales guiones, alojados por personas que ni siquiera se conocen). Y esto seguro que es más ligero que el correo electrónico (que, debido a los filtros de spam por lo menos, no funcionaría de todos modos).

 36
Author: anon6439,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-22 01:16:44

En el caso limitado de los pares dentro de una intranet, es posible enviar un mensaje UDP de difusión a un puerto conocido pidiendo que los pares informen.

 8
Author: Oddthinking,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-22 00:31:00

Aproveche cualquier foro existente donde se puedan publicar datos. Piense en el canal IRC secreto, incrustar datos en fotos y publicar en sitios para compartir fotos 4chan?, cualquier sitio que permitiría a su aplicación para iniciar sesión y publicar datos sin captia inicios de sesión, etc.

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

Otra estrategia podría ser incrustar mensajes en transacciones de moneda digital. Elige una moneda barata que sea probable que se quede ... DOGE o MOON coin tal vez. Construir funcionalidad de cartera en su aplicación. de modo que pueda publicar micro transacciones de ida y vuelta entre las direcciones que controla su aplicación. Todavía habría una tarifa de mineros, pero esto es solo fracciones de centavos. Incluso si luego prohíben agregar metadatos a las transacciones, podría realizar una transacción equivalente a su dirección IP en MOON y usar direcciones de vanidad en MOON coin para su aplicación. de tal manera que cuando un nuevo nodo se conecta, sabe qué buscar en la cadena de bloques 2 2daMOON%bootStr@pM3. SEND-104.003021133 MOON IP = 104.3.21.133 no es una propuesta costosa.

 6
Author: user6265,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-03-17 22:39:13

El cliente BitcoinQT utiliza una variedad de métodos para encontrar nodos, algunos de ellos pueden ser útiles para usted.

Descubrimiento de nodos de Cliente Satoshi

El IRC ya no se usa, pero podría ser el más fácil de implementar:

A partir de la versión 0.6.x el cliente Bitcoin ya no usa el bootstrapping de IRC por defecto, y a partir de la versión 0.8.2 el soporte para bootstrapping de IRC ha sido eliminado por completo. Esta documentación a continuación es precisa para la mayoría de las versiones anteriores.

En además de aprender y compartir su propia dirección, el nodo aprendió sobre otras direcciones de nodo a través de un canal IRC. Véase irc.cpp .

Después de aprender su propia dirección, un nodo codificó su propia dirección en una cadena para ser utilizada como un apodo. Luego, se unió aleatoriamente a un canal de IRC llamado entre #bitcoin00 y #bitcoin99. Luego emitió una orden de la OMS. El hilo lee las líneas tal como aparecen en el canal y decodifica las direcciones IP de otros nodos en el canal. Hizo esto en un bucle, para siempre, hasta que el nodo se apagó.

Cuando el cliente descubrió una dirección de IRC, estableció la marca de tiempo en la dirección a la hora actual, pero usó una "penalización" de 51 minutos, lo que significa que parecía que realmente se había visto casi una hora antes.

 5
Author: David,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-05-19 13:41:53

Tres maneras, de la parte superior de mi cabeza, aunque siempre vas a necesitar algún servidor central para iniciar la conexión a menos que se fue con la opción 3.

  • Servidor central que mantiene la lista conocida de pares, con keep-alive.
  • Uno o más servidores centrales que mantienen algunos pares de recursos comunes pueden usar para descubrirse entre sí, pero una vez conectados ya no necesitan el servidor central mientras el par permanezca conectado (algo como BitTorrent); pueden encadenar conexiones peered También.
  • Exploración de puertos/IP (no se recomienda).

En su ejemplo, todavía tendría algún tipo de servidor central donde se registrarían los pares; el protocolo es la única diferencia.

 4
Author: GalacticCowboy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-22 00:27:21

Para decirlo simplemente no, no hay manera de hacer esto sin un sever central.

Si desea hacer esto, simplemente necesita uno o más servidores centrales, ya sea por dns dinámico o no. Los clientes necesitan un método para descubrir a dónde deben conectarse, y la única manera realmente sensata de hacerlo es con su propio servidor, en el escenario más simple solo necesita enviar una dirección IP en respuesta.

Los severs virtuales se pueden tener por alrededor de $15 / mes, lo que IMO es considerablemente más barato que intentar usar o abusar del ancho de banda de otra persona.


[Editar].

Para decirlo simplemente, hay otra manera, como sigue.

Después de reflexionar, creo que lo que haría es designar un conjunto de pares como controladores de clúster y usar un servicio DNS dinámico para permitir que otros pares descubran los controladores de clúster.

Elija un proveedor de DNS dinámico Lo llamaré myc.ath.cx (Uso http://www.dyndns.com/).

Cada par tiene que ser capaz de convertirse en un cluster controlador. Un controlador de clúster contendrá una lista de todos los otros pares conectados.

Cuando se inicia un par, busca myc.ath.cx e intenta conectar. Si la conexión no se puede realizar dentro de un período, digamos 30 segundos, se hace cargo del registro de la entrada DNS.

Cualquier peer que desee descubrir otros peers puede simplemente consultar myc.ath.cx y se proporcionará una lista

Todos los pares son responsables de descargar periódicamente la lista de pares, en caso de que lo necesiten controlador de cluster.

El controlador de clúster consultará periódicamente la entrada DNS - si ha cambiado desde su dirección IP, entonces sabe que ya no es el controlador de clúster - por lo que se pondrá en contacto con el controlador de clúster que actualmente tiene la entrada DNS y proporcionará su lista de hosts conocidos.

El controlador del clúster contactará periódicamente con los hosts de la lista para asegurarse de que siguen siendo válidos.

 3
Author: Richard Harrison,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-22 20:51:17

Vieja pregunta, pero he estado pensando en este problema yo mismo así que ad mis 2 centavos. En resumen, un servidor central no es necesario si un nodo es consciente de al menos un par válido. Cualquier miembro actual debe agregar nuevos nodos a la red (por ejemplo, invitado, o nodo genera otro nodo, dependiendo de su aplicación).

Suponiendo que:

  • Los agentes realizan un seguimiento de los pares; el tamaño de esta libreta de direcciones y cómo se gestionan las entradas dependerá de la naturaleza del sistema; por ejemplo, cuánto tiempo permanecen conectados los pares, si los pares usan direcciones estables

  • Los agentes comparten información de pares con otros pares

  • Al menos algunos agentes permanecen disponibles durante períodos relativamente largos de tiempo en relación con la frecuencia del nodo se conecta a la red para actualizar su libreta de direcciones (o los nodos tienen direcciones estables)

  • Además de las direcciones de pares, también se realiza un seguimiento de la información de disponibilidad (muchas opciones aquí dependiendo de su sistema. los ejemplos incluyen: si el par tiene una dirección estable, cuándo se vio por última vez, alguna métrica de disponibilidad, información de tipo de contenido / servicio, dirección válida-hasta el momento si se conoce)

  • Los nuevos agentes se inicializan con al menos un par válido (no tiene que ser un nodo central, puede ser cualquier nodo válido)

  • Se requerirán mecanismos de confianza si los pares maliciosos son una posibilidad

Cuando un par se conecta, consulta a los pares en su tabla de pares para descubrir cuáles están activos y tal vez elimina direcciones dinámicas caducadas. Los nodos intercambian información de pares y pueden vincularse ellos mismos. Este descubrimiento/intercambio de pares puede continuar un cierto número de saltos o a través de una caminata aleatoria hasta la lista de pares si tiene suficiente tamaño y/o calidad.

Algunos detalles más:

  • Los nodos se conectan y comparten información de pares con frecuencia relacionada con la frecuencia con la que cambian las direcciones de nodo, por lo que la libreta de direcciones no se vuelve obsoleta y el nodo se desconecta porque ninguno de ellos es anterior los pares están disponibles en sus últimas direcciones conocidas

  • Los nodos pueden necesitar limitar el número de pares que aceptan, para evitar la tendencia hacia la centralización alrededor de los nodos más estables.

  • Los nodos deben ser selectivos sobre los pares que mantienen; es decir, aquellos en los que son más propensos a intercambiar datos (por ejemplo, peso basado en el historial)

  • Los enlaces de nodos pueden ser asimétricos o simétricos dependiendo de la aplicación

 2
Author: Edward Kirton,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-09-04 19:14:04

Su método de envío de correo electrónico utiliza un servidor dedicado, sin embargo; el servidor de correo electrónico del par, para ser precisos.

Aproximadamente, no creo que sea posible sin usar algún tipo de almacenamiento o servidor dedicado (lo que hace el enfoque de correo electrónico, aunque sea oblicuamente) A menos que pueda caracterizar la conectividad a Internet que sus pares están utilizando.

Básicamente, si tienes un conjunto de X número de pares, que se conectan durante Y cantidad de tiempo, y luego están fuera de la red para Z cantidad de tiempo... esencialmente, puede construir una ecuación de probabilidad sobre la probabilidad de que el conjunto de pares que contactó por última vez esté todavía disponible; cuando esa probabilidad se aproxima a 1 (para un conjunto dado de X, Y y Z anteriores), lo más probable es que pueda mantener una red peer-to-peer sin usar almacenamiento.

Posiblemente más en el espíritu; en lugar de tener un "servidor central dedicado", use un simple servicio gratuito en línea para especificar una lista de pares. Configurar un grupo de yahoo, o algo como eso; los clientes pueden buscarlo automáticamente y obtener una dirección de pares desde la que consultar un conjunto de pares; el cliente puede codificarse con la autenticación para publicar en el grupo, y puede publicar periódicamente su dirección IP para que otros puedan solicitar el conjunto de pares activos conocidos.

Si desea ser realmente complicado, puede comenzar a usar básicamente métodos esteganográficos para ocultar la información de ubicación de los pares. Es decir, obtener una búsqueda de Google para "blah"; encontrar el primer sitio que aparece en los resultados que tiene una tablero de mensajes desprotegido (sin CAPTCHA); encuentra el tercer mensaje (o lo que sea) que comienza con "Indudablemente" (o lo que sea), y encuentra el encabezado del primer mensaje allí, y allí está la dirección IP de un par. Si eso no funciona, baja la lista de términos de búsqueda al siguiente.

Pero eso es astuto. :-)
 1
Author: Paul Sonier,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-22 00:31:20

¿Podría reutilizar un servidor dedicado existente para ese propósito?

Estoy pensando en particular en registrar cada uno de los pares con un DNS Dinámico, pero si estuviera dispuesto a ponerse un poco más feo, compartir el acceso a una cuenta conocida de Hotmail o Google Doc o similares.

 1
Author: Oddthinking,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-22 00:38:59

Puede usar un directorio central o algún tipo de protocolo de difusión para la detección de servicios. Suponiendo que usted podría conseguirlos indexados por Google, usted podría concebir un sistema por el cual cada par ejecuta un sitio web con algunas palabras únicas, raras contenidas en una página específica. A continuación, podría utilizar los resultados de búsqueda de Google basados en estas palabras para identificar a los pares potenciales. Esto sería esencialmente una transmisión por Internet (ruidosa y lenta).

Si la estructura de la página era un patrón bien conocido o información de conexión identificable contenida para ese par, sería fácil distinguirlos en los resultados de búsqueda. El uso de un directorio público de este tipo te deja abierto a nodos comprometidos en la red que se forma, pero esto es más o menos cierto de cualquier red P2P sin algún mecanismo de seguridad.

Conseguir los sitios web rastreados y altamente clasificados por Google (o algún otro motor de búsqueda) para su conjunto arcano particular de términos de búsqueda sería el truco. Puedo pensar en un par de formas, pero no son las que usaría. Para un servicio legítimo, prefiero gastar el dinero o encontrar un sitio web gratuito que podría funcionar como un directorio.

 1
Author: tvanfosson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-04-05 20:11:11

¿Qué pasa con otro sistema P2P construido específicamente para rastrear pares en línea de otros sistemas P2P?

Entonces reducimos el problema de encontrar pares para cualquier nuevo sistema P2P a simplemente encontrar pares para el sistema P2P 'principal', que le dará las direcciones de pares en línea para el sistema que está interesado en usar...

 1
Author: Ethan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-02-19 18:10:23

Este es un uso típico de un algoritmo de tabla hash distribuida. Yo sugeriría mirar algo como pastelería. Utiliza una red superpuesta (red de capa de aplicación) encima de otras capas.

Cada nodo tiene un GUID que se usa para enrutar solicitudes a través de la red de pares.

 0
Author: Steve,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-03-29 17:50:01

Si está buscando un servidor central ya establecido, vea la entrada de metaserver en la página aquí:
http://martindevans.appspot.com /
Puede registrar pares allí y luego otros pares pueden encontrarlos. Obviamente este es un servidor central, pero no requiere mantenimiento de su parte.

 0
Author: Martin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-06-21 21:39:48