Интересно е да се следи развојот на мрежата за споделување датотеки, но уште поинтересно е да се учествува во неа.
Денес, инсталирање и лансирање на модерна NMDC центар, новосоздадениот администратор добива пристап до скоро сите случувања и искуство акумулирано во оваа област на неговите претходници. Има систем подготвен за проширување и прилагодување, вклучително и со помош на бројни скрипти.
С ADC хабови инаку. Дизајнот на овој протокол е наменет да биде проширлив. Дали сакате нова функција? Па, понудете го, промовирајте го, спроведете го, спроведете го, искористете го.
Како резултат на тоа, можете, се разбира, да извадите готов центар од кутијата, но едноставното лансирање и заборавањето на тоа нема да биде добро. Проширливоста во историски контекст подразбира и присуство на различен број на различни функции на софтверот клиент и сервер, во зависност од верзијата. И она што ќе работи без проблеми за еден корисник може да биде некомпатибилно со клиентот на друг, и тоа мора да се земе предвид.
Ова се случи со IPv6. Старецот NMDC не знае како да го направи тоа во принцип, но самата ADC е подготвена за тоа. Сепак, не се толку едноставно.
Само малку теорија
„Активниот“ корисник може да прифати дојдовни врски. Всушност, барањето за поврзување кое доаѓа од него е всушност покана.
„Пасивен“ корисник генерално може да користи само појдовни барања. Преку хабот тој прашува активниот корисник испраќа покана - и врската е воспоставена.
И да, овој механизам не зависи од верзијата на користениот IP протокол.
Лебед, рак и штука
Ајде да зборуваме за клиентски софтвер.
Поддршка за IPv6 DC++ е од експериментална природа. Нема посебни поставки за него, и уште повеќе ми беше изненадувачки што видов различни режими на работа за различни верзии на IP, со пасивни само за шестата, но ова не е точно.
Не беше можно да се добие активниот режим при рачна конфигурација дури и кога експлицитно користевте IP домен со AAAA запис како WAN, но во автоматскиот режим користејќи UPnP сè работеше како што се очекуваше.
AirDC++ има и поддршка за IPv6 конекции, а се имплементира целосно одвоено од IPv4. Покрај тоа, овој клиент ги модифицира корисничките ознаки на таков начин што ќе ги прикажува режимите на работа за двата IP протоколи истовремено. Самите хабови не знаат како да го направат ова (сеуште), што е штета.
Морам веднаш да направам резервација: AirDC++ го прави ова сам и за себе. Во иднина, за погодност, ќе користам комбинации како AP или AA како индикација за активни или пасивни начини на работа за IPv4 и IPv6, соодветно, наместо нивно прикажување во ознаката за вистински клиент на вистинскиот центар. Тоа е важно.
Во нашиот експеримент ќе користиме FlylinkDC++ како клиент кој воопшто не е запознаен со IPv6. Исто така, треба да се забележи дека поддршката NATT за него во времето на пишувањето на овој напис никаде не беше спроведен.
почеток
Пред сè, ќе ги разгледаме очигледно невозможните врски помеѓу корисниците на различни верзии на IP протоколот. Ќе се користи за тестот Подготвен центар за IPv6 со ресурс А- и AAAA-записи за името на доменот што дејствува како негова адреса.
Имајте предвид дека кога (всушност) се обидувате да контактирате со корисник со IP адреса од верзијата XNUMX, се прикажува грешка.
Она што е важно е режимот на поврзување прикажан на хабот.
Клиентите без поддршка за IPv6 ќе мора да ги гледаат корисниците поврзани преку него како јасно пасивни, едноставно затоа што центарот не се населува за нив I4 или I6 поле соодветно.
FlylinkDC++ наспроти. IPv6
Во реалноста, ситуацијата е поедноставна и посложена во исто време.
AirDC++ наспроти. IPv6
Полесно бидејќи IPv6 има предност пред IPv4, и тоа е разбирливо. Преку него (иако прескокнувањето е достапно со користење на соодветната опција) ќе се воспостави врската со хабот, а активниот клиент ќе му ја понуди на пасивниот клиент за поврзување.
Потешко е, бидејќи ако има корисници со поддршка за IPv6 на хабот, но тие се поврзани строго преку IPv4 адреса, тогаш ...
... тогаш можете да се поврзете со нив (по случаен избор) без воопшто да имате IPv4.
Ве молиме имајте предвид дека далечинскиот клиент се назначил себеси како средство, но се третира како обврска. Зошто?
Фрли го во замав
Сега ајде да се обидеме да ги поврземе клиентите со различни, но вообичаени во однос на IPv4, множества на IP протокол за поддршка едни на други.
Да, штета е што пасивните корисници треба да пушат настрана. Но, ова не може да се помогне, бидејќи нивната видлива IP адреса не е особено важна - затоа тие се обврски.
Бах! Активниот клиент испраќа пасивна команда?.. Би било логично да се очекува „заглавена“ врска, но не, испаѓа под условите A4.
Зошто е тоа? Го контактираме развивачот и добиваме одговор:
ТМО не е добро ако другиот корисник не поддржува IPv6
И не можете да се расправате! Но, ова бара внатрешна логика, независна од центарот (види код тука и тука). Сè уште е невозможно да им се помогне на пасивните, бидејќи
Обидите за поврзување помеѓу клиенти со вообичаени комплети за поддршка на IP IPv6 изгледаат вака. Да ве потсетам, постигнете PA Не успеав за DC++.
И повторно изненадување. Излегува дека пасивниот режим за IPv6, што го демонстрира DC++, е или намерна лажна или грешка.
Што е следно?
Во моментов, постојат точно два начина за решавање на сите можни проблеми со поврзување на корисниците во различни режими и со различни групи на поддршка за IP протокол.
Првиот е целосно исклучување на IPv6 или, обратно, создавање центар за работа само преку него.
Второто е ова експанзија, која штотуку се приближува до фазата на тестирање.
Па, ако сте премногу мрзливи да го поставите активниот режим за работа во DC, запомнете:
Кој има, што ќе му се даде, а кој нема, ќе му се одземе и тоа што мисли дека го има. ДОБРО. 8:18