És interessant veure el desenvolupament de la xarxa per compartir fitxers, però encara és més interessant participar-hi.
Avui, instal·lant i llançant un modern NMDC hub, el nou administrador té accés a gairebé tots els desenvolupaments i experiència acumulats en aquesta àrea dels seus predecessors. Té un sistema preparat per a l'expansió i la personalització, fins i tot amb l'ajuda de nombrosos scripts.
С ADC hubs en cas contrari. El disseny d'aquest protocol pretén ser extensible. Vols una funció nova? Bé, oferir-lo, promocionar-lo, implementar-lo, implementar-lo, utilitzar-lo.
Com a resultat, podeu, per descomptat, treure un concentrador ja fet de la caixa, però simplement llançar-lo i oblidar-lo no serà bo. L'extensibilitat en un context històric també implica la presència d'un nombre diferent de funcions diferents del programari client i servidor, segons la versió. I el que funcionarà sense problemes per a un usuari pot ser incompatible amb el client d'un altre, i això s'ha de tenir en compte.
Això va passar amb IPv6. El vell NMDC no sap com fer-ho en principi, però el mateix ADC està preparat per a això. Tanmateix, no tot és tan senzill.
Només una mica de teoria
L'usuari "actiu" pot acceptar connexions entrants. En realitat, la sol·licitud de connexió que ve d'ell és en realitat invitació.
Un usuari "passiu" generalment només pot utilitzar sol·licituds sortints. A través del hub ell pregunta l'usuari actiu envia una invitació i s'estableix la connexió.
I sí, aquest mecanisme no depèn de la versió del protocol IP utilitzat.
Cigne, escamarlans i lluç
Parlem del programari client.
Suport IPv6 DC++ és de naturalesa experimental. No hi ha configuracions separades per a això, i va ser encara més sorprenent per a mi veure diferents modes de funcionament per a diferents versions d'IP, amb passiu només per a la sisena, però això no és exacte.
No va ser possible obtenir el mode actiu durant la configuració manual, fins i tot quan s'utilitzava explícitament un domini IP amb un registre AAAA com a WAN, però en mode automàtic amb UPnP tot va funcionar com s'esperava.
AirDC++ també té suport per a connexions IPv6 i s'implementa de manera totalment independent d'IPv4. A més, aquest client modifica les etiquetes d'usuari de manera que es mostrin els modes de funcionament dels dos protocols IP simultàniament. Els mateixos hubs no saben com fer-ho (encara), la qual cosa és una llàstima.
He de fer una reserva immediatament: AirDC++ ho fa sol i per si mateix. En el futur, per comoditat, utilitzaré combinacions com AP o AA com a indicació dels modes d'operació actius o passius per a IPv4 i IPv6, respectivament, en lloc de la seva visualització a l'etiqueta de client real del concentrador real. És important.
En el nostre experiment farem servir FlylinkDC++ com a client gens familiaritzat amb IPv6. També cal destacar aquest suport NATT per a ell en el moment d'escriure aquest article no es va implementar enlloc.
Начало
En primer lloc, veurem connexions òbviament impossibles entre usuaris de diferents versions del protocol IP. S'utilitzarà per a la prova Hub preparat per a IPv6 amb els registres de recursos A i AAAA per al nom de domini que actuen com a adreça.
Tingueu en compte que quan (de fet) intenteu contactar amb un usuari amb una adreça IP de la versió XNUMX, es mostra un error.
El que és important és el mode de connexió que es mostra al concentrador.
Els clients sense suport IPv6 hauran de veure els usuaris connectats a través d'ell com a clarament passius, simplement perquè el concentrador no s'omple per a ells. I4 o I6 camp en conseqüència.
FlylinkDC++ vs. IPv6
En realitat, la situació és més senzilla i més complexa alhora.
AirDC++ vs. IPv6
Més fàcil perquè IPv6 té prioritat sobre IPv4, i això és comprensible. És a través d'ell (tot i que la substitució està disponible mitjançant l'opció corresponent) que s'establirà la connexió amb el concentrador, i el client actiu l'oferirà al client passiu per a la connexió.
És més difícil, perquè si hi ha usuaris amb suport IPv6 al concentrador, però estan connectats estrictament mitjançant una adreça IPv4, aleshores...
... llavors us podeu connectar (a l'atzar) sense tenir IPv4 en absolut.
Tingueu en compte que el client remot s'ha designat com un actiu, però es tracta com un passiu. Per què?
Llança'l en un gronxador
Ara intentem connectar clients amb conjunts diferents, però comuns en termes d'IPv4, de suport de protocols IP entre ells.
Sí, és una llàstima que els usuaris passius hagin de fumar al marge. Però això no es pot evitar, ja que la seva adreça IP visible no és especialment important, per això són responsabilitats.
Bah! El client actiu envia comandament passiu?.. Seria lògic esperar una connexió "encallada", però no, resulta que sota les condicions A4.
Per què això? Ens posem en contacte amb el desenvolupador i obtenim la resposta:
CTM no és bo si l'altre usuari no és compatible amb IPv6
I no pots discutir! Però això requereix una lògica interna, independent del centre (vegeu el codi aquí и aquí). Encara és impossible ajudar els passius, perquè
Els intents de connectar-se entre clients amb conjunts comuns de suport IPv6 IP tenen aquest aspecte. Deixa'm recordar-te, aconseguir PA No vaig tenir èxit amb DC++.
I de nou una sorpresa. Resulta que el mode passiu per a IPv6, que demostra DC++, és una falsificació deliberada o un error.
Què serà el següent?
Actualment, hi ha exactament dues maneres de resoldre tots els possibles problemes de connexió dels usuaris en diferents modes i amb diferents conjunts de suport de protocols IP.
El primer és silenciar IPv6 per complet o, al contrari, crear un concentrador que només funcioni a través d'ell.
El segon és aquest extensió, que tot just s'acosta a l'etapa de proves.
Bé, si ets massa mandrós per configurar el mode actiu per treballar a DC, recorda:
A qui té, el que li serà donat, i a qui no té, fins i tot allò que creu que té, se li prendrà. D'ACORD. 8:18