Hè interessante per fighjà u sviluppu di a reta di spartera di file, ma hè ancu più interessante di participà à questu.
Oghje, stallà è lanciari un mudernu NMDC hub, l'amministratore di novu cuniate accede à quasi tutti i sviluppi è l'esperienza accumulate in questa zona di i so predecessori. Hà un sistema prontu per espansione è persunalizazione, ancu cù l'aiutu di numerosi script.
С ADC centri altrimenti. U disignu di stu protokollu hè destinatu à esse estensibile. Vulete una nova funzione? Ebbè, offre, prumove, implementà, implementà, aduprate.
In u risultatu, pudete, sicuru, uttene un hub prontu fora di a scatula, ma simpricimenti lancià è scurdà di questu ùn serà micca bonu. L'estensibilità in un cuntestu storicu implica ancu a prisenza di un numeru sfarente di diverse funzioni di u software di cliente è servitore, secondu a versione. E ciò chì hà da travaglià senza prublemi per un utilizatore pò esse incompatibile cù u cliente di l'altru, è questu deve esse cunsideratu.
Questu hè accadutu cù IPv6. U vechju NMDC ùn sapi micca cumu fà in principiu, ma ADC stessu hè prontu per questu. Tuttavia, micca tutti cusì sèmplice.
Solu un pocu di teoria
L'utilizatore "attivu" pò accettà e cunnessione entranti. In realtà, a dumanda di cunnessione chì vene da questu hè in realtà invitu.
Un utilizatore "passivu" pò generalmente aduprà solu richieste in uscita. À traversu u hub ellu dumanda l'utilizatore attivu manda un invitu - è a cunnessione hè stabilita.
È sì, stu mecanismu ùn dipende micca da a versione di u protocolu IP utilizatu.
Cigno, gambero e luccio
Parlemu di u software cliente.
Supportu IPv6 DC++ hè di natura sperimentale. Ùn ci sò micca paràmetri separati per questu, è era più surprisante per mè per vede diverse modi operativi per diverse versioni di IP, cù passive solu per u sestu, ma questu ùn hè micca precisu.
Ùn era micca pussibule di ottene u modu attivu durante a cunfigurazione manuale ancu quandu utilizendu esplicitamente un duminiu IP cù un registru AAAA cum'è WAN, ma in modu automaticu cù UPnP tuttu hà travagliatu cum'è previstu.
AirDC++ hà ancu supportu per e cunnessione IPv6, è hè implementatu completamente separatamente da IPv4. Inoltre, stu cliente modifica e tag di l'utilizatori in modu chì mostra i modi operativi per i dui protokolli IP simultaneamente. I centri stessi ùn sanu micca cumu fà questu (ancora), chì hè una pena.
Devu subitu fà una riservazione: AirDC++ face questu solu è per ellu stessu. In u futuru, per comodità, aduprà cumminzioni cum'è AP o AA cum'è un'indicazione di i modi di funziunamentu attivu o passivu per IPv4 è IPv6, rispettivamente, invece di a so visualizazione in u tag di cliente reale nantu à u centru reale. Hè impurtante.
In u nostru esperimentu avemu aduprà FlylinkDC++ cum'è un cliente micca familiarizatu cù IPv6. Hè ancu esse nutatu chì u sustegnu NATT per ellu à u mumentu di a scrittura di stu articulu ùn era micca implementatu in ogni locu.
U principiu
Prima di tuttu, guardemu à e cunnessione ovviamente impussibili trà l'utilizatori di diverse versioni di u protocolu IP. Serà utilizatu per a prova Hub prontu IPv6 cù risorsa A- è AAAA-records per u nome di duminiu chì agisce cum'è u so indirizzu.
Per piacè nutate chì quandu (in realtà) pruvate à cuntattà un utilizatore cù un indirizzu IP di versione XNUMX, un errore hè visualizatu.
Ciò chì hè impurtante hè u modu di cunnessione affissatu nantu à u hub.
I clienti senza supportu IPv6 anu da vede l'utilizatori cunnessi per ellu cum'è chjaramente passivi, solu perchè u hub ùn pò micca populatu per elli. I4 o I6 campu in cunsequenza.
FlylinkDC++ vs. IPv6
In realtà, a situazione hè più simplice è cumplessu à u stessu tempu.
AirDC++ vs. IPv6
Hè più faciule perchè l'IPv6 hà a precedenza annantu à l'IPv4, è questu hè comprensibile. Hè per ellu (ancu se l'override hè dispunibule cù l'opzione currispondente) chì a cunnessione à u hub serà stabilitu, è u cliente attivu l'offre à u cliente passiu per a cunnessione.
Hè più difficiule, perchè s'ellu ci sò utilizatori cù supportu IPv6 nantu à u hub, ma sò cunnessi strettamente per un indirizzu IPv4, allora ...
... allora pudete cunnette cun elli (à l'aleatoriu) senza avè IPv4 in tuttu.
Per piacè nutate chì u cliente remoto s'hè designatu cum'è un attivu, ma hè trattatu cum'è una responsabilità. Perchè?
Lanciallu in una altalena
Avà pruvemu à cunnette i clienti cù diversi, ma cumuni in termini di IPv4, setti di supportu di protocolu IP l'un à l'altru.
Iè, hè una disgrazia chì l'utilizatori passivi anu da fumà à u latu. Ma questu ùn pò micca esse aiutatu, postu chì u so indirizzu IP visibile ùn hè micca particularmente impurtante - hè per quessa chì sò passivi.
Bah! U cliente attivu manda cumanda passiva?.. Saria logicu à aspittà una cunnessione "stuck", ma no, risulta in e cundizioni A4.
Perchè hè questu? Cuntattatemu u sviluppatore è uttene a risposta:
CTM ùn hè micca bonu se l'altru utilizatore ùn sustene micca IPv6
È ùn pudete micca discutiri! Ma questu richiede una logica interna, indipendente da u hub (vede u codice ccà и ccà). Hè sempre impussibule di aiutà i passivi, perchè
I tentativi di cunnette trà i clienti cù setti cumuni di supportu IPv6 IP parenu cusì. Lasciami ricurdà, ghjunghje PA Ùn aghju micca successu per DC ++.
È dinò una sorpresa. Risulta chì u modu passiu per IPv6, chì DC ++ dimostra, hè o un falsu deliberatu o un bug.
Chi c'è vicinu?
Attualmente, ci sò esattamente duie manere di risolve tutti i prublemi pussibuli di cunnessione di l'utilizatori in diverse modi è cù diversi setti di supportu di protokollu IP.
U primu hè di mute IPv6 in tuttu o, à u cuntrariu, creà un hub per travaglià solu per ellu.
U sicondu hè questu allargamentu, chì hè ghjustu avvicinendu a fase di prova.
Ebbè, sè vo site troppu pigro per stabilisce u modu attivu per travaglià in DC, ricordate:
À quellu chì hà, ciò chì li serà datu, è à quellu chì ùn hà micca, ancu ciò chì pensa ch'ellu hà, li serà cacciatu. OK. 8:18