Gan ddefnyddio IPv6 gyda Chysylltiad Uniongyrchol Uwch

Mae'n ddiddorol gwylio datblygiad y rhwydwaith rhannu ffeiliau, ond mae hyd yn oed yn fwy diddorol cymryd rhan ynddo.

Heddiw, gosod a lansio modern NMDC both, mae'r gweinyddwr sydd newydd ei bathu yn cael mynediad i bron yr holl ddatblygiadau a'r profiad a gronnwyd yn y maes hwn o'i ragflaenwyr. Mae ganddo system sy'n barod i'w ehangu a'i haddasu, gan gynnwys gyda chymorth nifer o sgriptiau.

С ADC canolbwyntiau fel arall. Bwriedir i ddyluniad y protocol hwn fod yn estynadwy. Ydych chi eisiau nodwedd newydd? Wel, ei gynnig, ei hyrwyddo, ei roi ar waith, ei roi ar waith, ei ddefnyddio.

Cyfieithu i'r Saesneg

O ganlyniad, gallwch, wrth gwrs, gael canolbwynt parod allan o'r bocs, ond ni fydd yn dda ei lansio ac anghofio amdano. Mae estynadwyedd mewn cyd-destun hanesyddol hefyd yn awgrymu presenoldeb nifer wahanol o wahanol swyddogaethau meddalwedd cleient a gweinydd, yn dibynnu ar y fersiwn. A gall yr hyn a fydd yn gweithio heb broblemau i un defnyddiwr fod yn anghydnaws â chleient un arall, a rhaid cymryd hyn i ystyriaeth.

Digwyddodd hyn gyda IPv6. Nid yw'r hen ddyn NMDC yn gwybod sut i'w wneud mewn egwyddor, ond mae ADC ei hun yn barod ar ei gyfer. Fodd bynnag, nid yw pob un mor syml.

Dim ond ychydig o theori

Gall y defnyddiwr "gweithredol" dderbyn cysylltiadau sy'n dod i mewn. Mewn gwirionedd, mae'r cais cysylltiad sy'n dod ohono mewn gwirionedd gwahoddiad.

Yn gyffredinol, dim ond ceisiadau sy'n mynd allan y gall defnyddiwr "goddefol" eu defnyddio. Trwy y both he yn gofyn mae'r defnyddiwr gweithredol yn anfon gwahoddiad - ac mae'r cysylltiad wedi'i sefydlu.

Ac ie, nid yw'r mecanwaith hwn yn dibynnu ar y fersiwn o'r protocol IP a ddefnyddir.

Alarch, cimwch yr afon a phenhwyaid

Gadewch i ni siarad am feddalwedd cleient.

Cefnogaeth IPv6 DC++ yn arbrofol ei natur. Nid oes unrhyw osodiadau ar wahân ar ei gyfer, ac roedd yn fwy o syndod i mi weld gwahanol ddulliau gweithredu ar gyfer gwahanol fersiynau o IP, gyda goddefol yn unig ar gyfer y chweched, ond nid yw hyn yn gywir.

Nid oedd yn bosibl cael y modd gweithredol yn ystod cyfluniad llaw hyd yn oed wrth ddefnyddio parth IP yn benodol gyda chofnod AAAA fel WAN, ond yn y modd awtomatig gan ddefnyddio UPnP roedd popeth yn gweithio yn ôl y disgwyl.

AirDC++ mae ganddo hefyd gefnogaeth ar gyfer cysylltiadau IPv6, ac fe'i gweithredir yn gyfan gwbl ar wahân i IPv4. Ar ben hynny, mae'r cleient hwn yn addasu tagiau defnyddwyr yn y fath fodd ag i arddangos dulliau gweithredu ar gyfer y ddau brotocol IP ar yr un pryd. Nid yw'r canolbwyntiau eu hunain yn gwybod sut i wneud hyn (eto), sy'n drueni.

Rhaid i mi wneud archeb ar unwaith: mae AirDC++ yn gwneud hyn ar ei ben ei hun ac ar ei ben ei hun. Yn y dyfodol, er hwylustod, byddaf yn defnyddio cyfuniadau fel AP neu AA fel arwydd o ddulliau gweithredu gweithredol neu oddefol ar gyfer IPv4 a IPv6, yn y drefn honno, yn hytrach na'u harddangos yn y tag cleient go iawn ar y canolbwynt go iawn. Mae'n bwysig.

Yn ein harbrawf byddwn yn defnyddio FlylinkDC++ fel cleient nad yw'n gyfarwydd o gwbl ag IPv6. Dylid nodi hefyd y gefnogaeth honno NATT iddo ar adeg ysgrifennu'r erthygl hon nid oedd yn gweithredu yn unman.

Dechrau

Yn gyntaf oll, byddwn yn edrych ar gysylltiadau amlwg amhosibl rhwng defnyddwyr gwahanol fersiynau o'r protocol IP. Bydd yn cael ei ddefnyddio ar gyfer y prawf IPv6 canolbwynt parod gyda chofnodion adnoddau A- ac AAAA ar gyfer yr enw parth yn gweithredu fel ei gyfeiriad.

Sylwch, pan fyddwch chi (mewn gwirionedd) yn ceisio cysylltu â defnyddiwr gyda chyfeiriad IP fersiwn XNUMX, mae gwall yn cael ei arddangos.

Hub:	[Outgoing][IPv4:412]	 	DRCM AACX AACU ADCS/0.10 337151563
Hub:	[Incoming][IPv4:412]	 	DCTM AACU AACX ADCS/0.10 1988 337151563
Hub:	[Outgoing][IPv4:412]	 	DSTA AACX AACU 240 IPsunknown

Mewn cyfieithiad dynol mae'n swnio fel

P4: - A allaf lynu wrthych?
A6: - Glynu ymlaen!
P4: - Mae bywyd yn boen 0_0

Geiriadur byr, os oes angen, yma.

Ac os yw'r ffordd arall o gwmpas, a bod y cysylltiad yn cychwyn A4, yna nid oes gwall yn cael ei arddangos ac mae'r cysylltiad yn hongian yn syml.

Hub:	[Outgoing][IPv4:412]	 	DCTM AACX AACU ADCS/0.10 1993 3871342713

Byddwch, nid yw'n ymddangos

Yr hyn sy'n bwysig yw'r modd cysylltu a ddangosir ar y canolbwynt.

Bydd yn rhaid i gleientiaid heb gefnogaeth IPv6 weld defnyddwyr sy'n gysylltiedig trwyddo yn amlwg yn oddefol, yn syml oherwydd nad yw'r canolbwynt yn llenwi ar eu cyfer I4 neu I6 maes yn unol â hynny.

FlylinkDC++ yn erbyn. IPv6

Mewn gwirionedd, mae'r sefyllfa'n symlach ac yn fwy cymhleth ar yr un pryd.

AirDC++ yn erbyn. IPv6

Haws oherwydd mae IPv6 yn cael blaenoriaeth dros IPv4, ac mae hynny'n ddealladwy. Trwyddo (er bod gwrthwneud ar gael gan ddefnyddio'r opsiwn cyfatebol) y bydd y cysylltiad â'r canolbwynt yn cael ei sefydlu, a bydd y cleient gweithredol yn ei gynnig i'r cleient goddefol i'w gysylltu.

Mae'n anoddach, oherwydd os oes defnyddwyr â chefnogaeth IPv6 ar y canolbwynt, ond eu bod wedi'u cysylltu'n llym trwy gyfeiriad IPv4, yna ...

... yna gallwch gysylltu â nhw (ar hap) heb gael IPv4 o gwbl.

Sylwch fod y cleient o bell wedi dynodi ei hun fel ased, ond yn cael ei drin fel rhwymedigaeth. Pam?

Taflwch ef mewn siglen

Nawr, gadewch i ni geisio cysylltu cleientiaid â setiau gwahanol, ond cyffredin o ran IPv4, o gefnogaeth protocol IP i'w gilydd.

Ydy, mae'n drueni bod yn rhaid i ddefnyddwyr goddefol ysmygu ar y llinell ochr. Ond ni ellir helpu hyn, gan nad yw eu cyfeiriad IP gweladwy yn arbennig o bwysig - dyna pam eu bod yn rhwymedigaethau.

Ystyr geiriau: Bah! Mae'r cleient gweithredol yn anfon gorchymyn goddefol?... Byddai'n rhesymegol disgwyl cysylltiad “sownd”, ond na, mae'n troi allan o dan yr amodau A4.

Pam hynny? Rydym yn cysylltu â'r datblygwr ac yn cael yr ateb:

CTM ddim yn dda os nad yw'r defnyddiwr arall yn cefnogi IPv6

Ac ni allwch ddadlau! Ond mae hyn yn gofyn am resymeg fewnol, yn annibynnol ar y canolbwynt (gweler y cod yma и yma). Mae'n dal yn amhosibl i helpu goddefol, oherwydd

Modd gweithredol = TCPx+IPx

Mae ymdrechion i gysylltu rhwng cleientiaid â setiau cymorth IP IPv6 cyffredin yn edrych fel hyn. Gadewch imi eich atgoffa, cyflawni PA Wnes i ddim llwyddo i DC++.

Ac eto yn syndod. Mae'n ymddangos bod y modd goddefol ar gyfer IPv6, y mae DC ++ yn ei ddangos, naill ai'n ffug bwriadol neu'n fyg.

Beth sydd nesaf?

Ar hyn o bryd, mae dwy ffordd union i ddatrys yr holl broblemau posibl sy'n cysylltu defnyddwyr mewn gwahanol ddulliau a gyda gwahanol setiau o gefnogaeth protocol IP.

Y cyntaf yw tewi IPv6 yn gyfan gwbl neu, i'r gwrthwyneb, creu canolbwynt i weithio trwyddo yn unig.

Yr ail un yw hwn ehangu, sydd newydd agosáu at y cam profi.

Wel, os ydych chi'n rhy ddiog i sefydlu'r modd gweithredol ar gyfer gweithio yn DC, cofiwch:

Pwy bynnag sydd ganddo, beth a roddir iddo, a phwy bynnag nad oes ganddo, bydd hyd yn oed yr hyn y mae'n ei feddwl sydd ganddo yn cael ei gymryd oddi wrtho. IAWN. 8:18

Ffynhonnell: hab.com