p2p - instruction - Peer to Peer: métodos de búsqueda de pares

peer instruction flipped classroom (13)

¿Podría volver a utilizar un servidor dedicado existente para este fin?

En particular, estoy pensando en registrar a cada uno de los pares con un DNS dinámico, pero si está dispuesto a ponerse un poco más feo, comparta el acceso a una cuenta conocida de Hotmail o a un documento de Google Docs o similar.

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

es decir: si tengo compañeros que se desconectan y se vuelven a conectar a Internet, pero obteniendo una nueva dirección IP cada vez, y quiero conectarme a ellos sin configurar un servidor dedicado para registrarme.

Estaba pensando en usar la dirección de correo electrónico de mis compañeros para enviar un manifiesto de mis compañeros conectados periódicamente, con algún tipo de código de tiempo, anulando la necesidad de un servidor dedicado. Esto sería un retroceso si ninguno de los pares se pudiera conectar después de probar todas las direcciones pares conocidas previamente. Pero los modelos existentes de búsqueda de pares serían preferibles.

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

No hay forma de evitar tener que saber al menos un par inicial para descubrir más. Los protocolos P2P completos, como Gnutella o Gnutella2, o el Overnet más simple (hecho famoso por Storm Worm), se basan en que cada cliente tenga una lista de inicio de algunos pares. Estos pueden desprenderse de un rastreador automático basado en la web, por ejemplo. El cliente descubrirá toda la red o partes de ella pidiendo más direcciones a otros compañeros, por ejemplo, al delegar una búsqueda de archivos.

Si realmente no puedes tener ningún tipo de recurso centralizado, lo mejor que puedes hacer es encontrar el primer par a través de mensajes emitidos y, en última instancia, escaneo de direcciones IP. El primer enfoque es bueno, pero en al menos el 98% de los casos no arrojará ningún resultado. El enfoque posterior, por supuesto, es abusar 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 en día, está contenida por diez y veinte scripts, alojados por personas que ni siquiera se conocen). Y esto es más ligero que el correo electrónico (que, como mínimo, debido a los filtros de spam, no funcionaría de todos modos).

Para decirlo simplemente no, no hay forma de hacerlo sin un servidor central.

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

Se pueden obtener servidores virtuales por alrededor de $ 15 al mes, lo que IMO es considerablemente más económico que tratar de 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 del clúster.

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

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

Cuando un compañero se inicia, busca myc.ath.cx e intenta conectarse. 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 compañero que desee descubrir a otros pares simplemente puede consultar myc.ath.cx y se le proporcionará una lista

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

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

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

Sin embargo, su método de envío de correos usa un servidor dedicado; el servidor de correo electrónico del par, para ser precisos.

A grandes rasgos, no creo que sea posible sin utilizar algún tipo de almacenamiento o servidor dedicado (lo que el enfoque de correo electrónico hace, aunque de manera oblicua) A MENOS QUE pueda caracterizar la conectividad a Internet que utilizan sus pares.

Básicamente, si tienes un conjunto de X pares, se conectan durante una cantidad Y de tiempo, y luego están fuera de la cuadrícula por una cantidad de tiempo Z ... esencialmente, puedes construir una ecuación de probabilidad acerca de qué tan probable es que el grupo de pares con el que contactó por última vez todavía está disponible; donde esa probabilidad se aproxima a 1 (para un conjunto dado de X, Y y Z anterior), lo más probable es que pueda mantener una red de igual a igual 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. Configura un grupo yahoo, o algo así; los clientes pueden buscarlo automáticamente y obtener una dirección de pares desde la cual 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 quieres ponerte realmente complicado, puedes comenzar a utilizar básicamente métodos esteganográficos para ocultar la información de ubicación de tus compañeros. Es decir, obtener una búsqueda de Google para "bla"; encuentre el primer sitio enumerado en los resultados que tiene un tablero de mensajes desprotegido (sin CAPTCHA); encuentre la tercera (o lo que sea) publicación que comience con "Indubitablemente" (o lo que sea), y encuentre el encabezado del primer mensaje allí, y allí está la dirección IP de un compañero. Si eso no funciona, baje la lista de términos de búsqueda a la siguiente.

Pero eso es astuto. :-)

Tres maneras, fuera de lo común, aunque siempre vas a necesitar un servidor central para iniciar la conexión, a menos que fueras con la opción 3.

Servidor central que mantiene una lista conocida de pares, con keep-alive.
Uno o más servidores centrales que mantienen algunos pares de recursos comunes pueden utilizar para descubrirse entre sí, pero una vez que están conectados ya no necesitan el servidor central mientras el interlocutor permanezca conectado (algo así como BitTorrent); también puede encadenar conexiones peering.
Exploración de puerto / IP ( no recomendado ).

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

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

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

Si está buscando un servidor central ya establecido, consulte la entrada del metaservidor 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.

Puede usar un directorio central o algún tipo de protocolo de difusión para el descubrimiento de servicios. Suponiendo que Google pueda indexarlos, podría concebir un sistema mediante el cual cada uno de los pares ejecute un sitio web con algunas palabras únicas y excepcionales que figuran en una página específica. A continuación, puede utilizar los resultados de búsqueda de Google basados en estas palabras para identificar compañeros potenciales. Esto sería esencialmente una transmisión de Internet (ruidosa y lenta).

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

Conseguir que los sitios web sean rastreados y altamente calificados por Google (u otro motor de búsqueda) para su arcano conjunto 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 pueda funcionar como un directorio.

¿Qué hay de otro sistema P2P creado específicamente para rastrear pares en línea de otros sistemas P2P?

Luego, reducimos el problema de encontrar pares para cualquier sistema P2P nuevo simplemente buscando pares para el sistema P2P "principal", que le dará las direcciones de pares en línea para el sistema que le interesa usar ...

Aproveche cualquier foro existente donde se puedan publicar los datos. Piensa en el canal secreto de IRC, incrustando datos en fotos y publicando en sitios de intercambio de fotos 4chan ?, cualquier sitio que permita a tu aplicación iniciar sesión y publicar datos sin inicios de sesión de captia, etc.

http://chatzilla.hacksrus.com/faq/#contraseña

Otra estrategia podría ser insertar mensajes en transacciones de moneda digital. Elija una moneda barata que probablemente se quede ... DOGE o MOON coin maybe. Crea la funcionalidad de billetera en tu aplicación. de modo que puede publicar micro transacciones 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, puede realizar una transacción equivalente a su dirección IP en MOON, y usar direcciones vanity en moneda MOON para su aplicación. de modo que cuando un nuevo nodo se conecta, sepa en qué buscar el blockchain: 2daMOON% bootStr @ pM3. ENVIAR - 104.003021133 MOON IP = 104.3.21.133 no es una propuesta costosa.

El cliente BitcoinQT usa una variedad de métodos para encontrar nodos, algunos de ellos pueden serle útiles.

Descubrimiento de nodo de cliente de Satoshi

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 de Bitcoin ya no usa bootstrapping de IRC por defecto, y desde 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.
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. Ver irc.cpp .
Después de aprender su propia dirección, un nodo codificó su propia dirección en una cadena para usarla como apodo. Luego, se unió aleatoriamente a un canal de IRC nombrado entre # bitcoin00 y # bitcoin99. Luego emitió un comando de la OMS. El hilo leyó las líneas tal como aparecían en el canal y decodificó 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 se había visto casi una hora antes.

Una vieja pregunta, pero he estado pensando en este problema yo mismo así que voy a mis 2 centavos. En resumen, no se requiere un servidor central si un nodo conoce al menos un par válido. Los nuevos nodos deben ser agregados a la red por cualquier miembro actual (por ejemplo, invitado, o el nodo genera otro nodo, dependiendo de su aplicación).

Asumiendo que:

los agentes hacen un seguimiento de los compañeros; el tamaño de esta libreta de direcciones y cómo se administran 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 entre iguales con otros pares
al menos algunos agentes permanecen disponibles durante períodos de tiempo relativamente largos en relación con el nodo de frecuencia que se conecta a la red para actualizar su libreta de direcciones (o los nodos tienen direcciones estables)
Además de las direcciones pares, también se realiza un seguimiento de la información de disponibilidad (aquí hay muchas opciones dependiendo de su sistema. Ejemplos incluyen: si el par tiene una dirección estable, la última vez que se vio, alguna métrica de disponibilidad, información del tipo de contenido / servicio, dirección válida; conocido)
los nuevos agentes se inicializan con al menos un par válido (no tiene que ser un nodo central, puede ser un nodo válido)
se requerirán mecanismos de confianza si hay pares malintencionados

Cuando un par entra en línea, consulta a los pares en su tabla de pares para descubrir cuáles están activos y quizás quita las direcciones dinámicas caducadas. Los nodos intercambian información entre iguales y pueden vincularse ellos mismos. Este descubrimiento / intercambio de pares puede continuar un cierto número de saltos o mediante una caminata aleatoria hasta que la lista de pares tenga un tamaño y / o calidad suficientes.

Algunos detalles más:

Los nodos se conectan y comparten información entre pares con frecuencia relacionada con la frecuencia con la que cambian las direcciones de los nodos, por lo que la libreta de direcciones no se queda obsoleta y el nodo se desconecta porque ninguno de sus pares anteriores está disponible en sus últimas direcciones conocidas
Los nodos pueden necesitar limitar el número de pares que aceptan, para evitar la tendencia a la centralización alrededor de los nodos más estables.
Los nodos deben ser selectivos sobre los pares que guardan; es decir, aquellos en los que es más probable que intercambien datos (p. ej., peso según el historial)
Los enlaces de nodo pueden ser asimétricos o simétricos dependiendo de la aplicación