Es interesante observar el desarrollo de la red para compartir archivos, pero es aún más interesante participar en ella.
Hoy, instalar y lanzar un moderno NMDC hub, el nuevo administrador tiene acceso a casi todos los desarrollos y la experiencia acumulada en esta área por sus predecesores. Tiene un sistema listo para ampliación y personalización, incluso con la ayuda de numerosos scripts.
С ADC de lo contrario. El diseño de este protocolo pretende ser extensible. ¿Quieres una nueva característica? Pues ofrécelo, promuévelo, impleméntalo, impleméntalo, úsalo.
Como resultado, puede, por supuesto, obtener un centro listo para usar, pero simplemente ejecutarlo y olvidarse de él no será bueno. La extensibilidad en un contexto histórico también implica la presencia de un número diferente de funciones diferentes del software cliente y servidor, según la versión. Y lo que funcionará sin problemas para un usuario puede ser incompatible con el cliente de otro, y esto hay que tenerlo en cuenta.
Esto sucedió con IPv6. El viejo NMDC no sabe cómo hacerlo en principio, pero el propio ADC está preparado para ello. Sin embargo, no todo es tan sencillo.
Un poco de teoría
El usuario "activo" puede aceptar conexiones entrantes. En realidad, la solicitud de conexión que proviene de él es en realidad invitación.
Un usuario "pasivo" generalmente sólo puede utilizar solicitudes salientes. A través del centro él просит el usuario activo envía una invitación y se establece la conexión.
Y sí, este mecanismo no depende de la versión del protocolo IP utilizado.
Cisne, Cáncer y Lucio
Hablemos del software cliente.
soporte IPv6 DC ++ es de naturaleza experimental. No hay configuraciones separadas para ello, y fue aún más sorprendente para mí ver diferentes modos de funcionamiento para diferentes versiones de IP, con pasivo solo para la sexta, pero esto no es exacto.
No fue posible obtener el modo activo durante la configuración manual incluso cuando se usaba explícitamente un dominio IP con un registro AAAA como WAN, pero en el modo automático usando UPnP todo funcionó como se esperaba.
AirDC ++ También tiene soporte para conexiones IPv6 y se implementa de forma completamente independiente de IPv4. Además, este cliente modifica las etiquetas de usuario de tal manera que muestre los modos de funcionamiento de ambos protocolos IP simultáneamente. Los propios centros no saben cómo hacer esto (todavía), lo cual es una lástima.
Debo hacer una reserva inmediatamente: AirDC++ hace esto solo y por sí mismo. En el futuro, por conveniencia, usaré combinaciones como AP o AA como una indicación de los modos de operación activo o pasivo para IPv4 e IPv6, respectivamente, en lugar de su visualización en la etiqueta del cliente real en el concentrador real. Es importante.
En nuestro experimento usaremos FlylinkDC ++ como cliente que no está nada familiarizado con IPv6. También cabe señalar que el apoyo NATT para él en el momento de escribir este artículo no se había implementado en ninguna parte.
principio
En primer lugar, veremos conexiones obviamente imposibles entre usuarios de diferentes versiones del protocolo IP. Se utilizará para la prueba. Centro preparado para IPv6 con registros de recurso A y AAAA para el nombre de dominio que actúan como su dirección.
Tenga en cuenta que cuando (realmente) intenta contactar a un usuario con una dirección IP de la versión XNUMX, se muestra un error.
Lo importante es el modo de conexión que se muestra en el concentrador.
Los clientes sin soporte IPv6 tendrán que ver a los usuarios conectados a través de él como claramente pasivos, simplemente porque el concentrador no se llena para ellos. I4 o I6 campo en consecuencia.
FlylinkDC++ vs. IPv6
En realidad, la situación es más sencilla y más compleja al mismo tiempo.
AirDC++ vs. IPv6
Es más fácil porque IPv6 tiene prioridad sobre IPv4, y eso es comprensible. Es a través de él (aunque la anulación está disponible usando la opción correspondiente) que se establecerá la conexión al hub y el cliente activo se lo ofrecerá al cliente pasivo para que se conecte.
Es más difícil, porque si hay usuarios con soporte IPv6 en el hub, pero están conectados estrictamente a través de una dirección IPv4, entonces...
... entonces podrás conectarte a ellos (al azar) sin tener ningún IPv4.
Tenga en cuenta que el cliente remoto se ha designado a sí mismo como un activo, pero se lo trata como un pasivo. ¿Por qué?
Tíralo en un columpio
Ahora intentemos conectar clientes con conjuntos de protocolos IP diferentes, pero comunes en términos de IPv4, entre sí.
Sí, es una lástima que los usuarios pasivos tengan que fumar al margen. Pero esto no se puede evitar, ya que su dirección IP visible no es particularmente importante, por eso son responsabilidades.
¡Bah! El cliente activo envía comando pasivo?.. Sería lógico esperar una conexión "atascada", pero no, resulta que en las condiciones A4.
¿Porqué es eso? Nos ponemos en contacto con el desarrollador y obtenemos la respuesta:
CTM no es bueno si el otro usuario no soporta IPv6
¡Y no puedes discutir! Pero esto requiere lógica interna, independiente del hub (ver código aquí и aquí). Todavía es imposible ayudar a los pasivos, porque
Los intentos de conectarse entre clientes con conjuntos de soporte IP IPv6 comunes se ven así. Déjame recordarte, lograr PA No tuve éxito con DC++.
Y de nuevo una sorpresa. Resulta que el modo pasivo para IPv6, que DC++ demuestra, es una falsificación deliberada o un error.
¿Qué será lo próximo?
Actualmente, existen exactamente dos formas de resolver todos los posibles problemas al conectar a los usuarios en diferentes modos y con diferentes conjuntos de soporte de protocolo IP.
La primera es silenciar IPv6 por completo o, por el contrario, crear un concentrador que funcione sólo a través de él.
El segundo es este extensión, que apenas se acerca a la etapa de prueba.
Bueno, si eres demasiado vago para configurar el modo activo para trabajar en DC, recuerda:
Al que tiene, lo que le será dado, y al que no tiene, hasta lo que cree tener le será quitado. Lx 8:18