Avanceret direkte forbindelse - Advanced Direct Connect

Avanceret direkte forbindelse
Protokolversion: 1.0.3
Udvidelsesversion 1.0.8
http://www.adc.sourceforge.net
Protokol
Udvidelser

Advanced Direct Connect ( ADC ) er en peer-to-peer-fildelings- og chatprotokol, der bruger samme netværkstopologi , koncepter og terminologi som Direct Connect (DC) -protokollen.

"ADC" er uofficielt et akronym for "Advanced Direct Connect".

Historie

ADC blev oprettet for at tillade en udvidelig protokol og for at løse nogle mangler ved Direct Connect-protokollen . Det blev initieret af Jacek Sieka under indflydelse af Jan Vidar Kreys DCTNG- udkast. Den første revision af ADC kom i 2004 og den første officielle version i 2007-12-01.

Design og funktioner

ADC er struktureret omkring klienter, der opretter forbindelse til en central hub, hvor klienterne (brugere) kan chatte og downloade filer fra andre klienter (brugere). Navet giver routing mellem klienter til chat, søgninger og anmodninger om forbindelser. Den faktiske filoverførsel er mellem klienter.

Selve protokollen er opdelt i to dele: en basisprotokol, som henholdsvis hver klient og hub skal følge, og udvidelser, der er valgfri. Protokollerne tillader signalering af protokolfunktioner (såsom blomstringsfiltre ), og meddelelser kan konstrueres til kun at blive dirigeret til dem, der understøtter den særlige funktion.

Hver hub har deres egne regler og styres ofte af huboperatører. Hubs kan definere forskellige muligheder for huboperatører. Navene selv regulerer ikke diskussion og filer, men huboperatørerne. Navet regulerer mindste andel og maksimal mængde samtidige nav; ting, der sendes af klienten snarere end brugeren.

Der findes lister over nav, hvor et navs navn, beskrivelse, adresse og regler er specificeret. Med navlisten kan brugerne vælge nav, der ligner alt efter brugerens smag af diskussionsemner og filer.

Peer-to-peer-delen af ​​protokollen er baseret på begrebet "slots" (svarende til antallet af åbne positioner for et job). Disse slots angiver antallet af personer, der til enhver tid har tilladelse til at downloade fra en bruger. Pladserne styres af brugeren af ​​den respektive klient.

ADC kræver, at al tekst skal sendes i UTF-8 , hvilket betyder, at brugere med andet system kodning (sige, russisk og kinesisk) er i stand til at chatte med respektive indfødte tegn.

Protokollen understøtter indbygget IPv6 .

Der er to tilstande, som en bruger kan være i: "aktiv" eller "passiv". Klienter i aktiv tilstand kan downloade fra alle andre på netværket. Brugere af passiv tilstand kan kun downloade fra aktive brugere. Passive klienter vil blive sendt søgeresultater gennem hubben, mens aktive klienter modtager resultaterne direkte. En aktiv søger modtager (højst) 10 resultater pr. Bruger, og en passiv søger modtager (højst) 5 resultater pr. Bruger. NAT-traversal findes som en protokoludvidelse, der giver passive brugere mulighed for at oprette forbindelse til andre passive brugere.

Basisprotokollen kræver ikke kryptering , men der findes udvidelser for at give kryptering med TLS .

Filer i klientforbindelser identificeres ved deres hash , oftest Tiger Tree Hash . Hash-algoritmen forhandles med hubben og bruges i hele klient-hub-sessionen samt efterfølgende klient-klientforbindelser.

Protokol

ADC-protokollen er en tekstbaseret protokol, hvor kommandoer og deres information sendes i klar tekst undtagen under adgangskodeforhandling. Klient-serveren (såvel som klient-klienten, hvor man fungerer som en "server") aspekt af protokollen bestemmer, at klienten taler først, når der er oprettet en forbindelse. For eksempel, når en klient opretter forbindelse til en hubs stikkontakt, er klienten den første til at tale med hubben.

Protokollen kræver, at al tekst skal sendes som UTF-8- kodet Unicode , normaliseret i form C.

Der er ingen portindstillinger for hubs eller klienter.

Hub-adresser har følgende form: adc: //eksempel.com: 411, hvor 411 er porten.

Under udveksling af information om hub-klientprotokol tilbyder klienten et sæt hashes, den understøtter. Navet vælger en af ​​disse hashes, og den hash vil blive brugt under hele hub-klientsessionen. Hvis hub'en finder ud af, at klienten ikke understøtter et (vilkårligt) passende hash-sæt, rejses en fejl.

Den globale identifikationsplan er baseret på hash-sæt, der producerer to slut-hashes, hvor den ene afhænger af output fra den anden. Under hub-klient-informationsudveksling sender klienten disse slut-hashes, kodet med base32, som hub'en vil bekræfte at matche. En af disse base32-kodede hashes sendes yderligere til andre klienter i netværket. Den globale identifikationsplan er denne sidste streng. Klienten kan ændre sine slut-hashes på en hub-til-hub-basis.

Hver bruger tildeles under en hub-session en hash, der kun varer den pågældende session. Denne hash vil blive brugt til alle klientreferencer i den hub. Der er ingen afhængighed af kryds.

Hver klientinformationsmeddelelse sendes trinvist.

En indgående anmodning om en klient-klientforbindelse er knyttet til en faktisk forbindelse med brug af et token.

Søgninger bruger også et token til at identificere hvert resultat af en søgning.

Der er ingen out-of-the-box evne for en klient til at sparke eller omdirigere en anden klient fra et hub. Navet kan dog sparke og omdirigere vilkårligt. Navet kan også kræve, at alle andre klienter i hubben skal afslutte deres overførsler med den sparkede / omdirigerede klient. Hvis en klient omdirigeres til en anden hub, skal den omdirigerende klient bruge en henvisning, der ligner HTTP-henviseren . Den sparkede / omdirigerede klient er ikke forpligtet til at modtage en besked.

Peer-to-peer-delen af ​​protokollen er baseret på begrebet "slots" (svarende til antallet af åbne positioner for et job). Disse slots angiver antallet af personer, der til enhver tid har tilladelse til at downloade fra en bruger. Disse slots kontrolleres af klienten. Automatisk tildeling af slot understøttes af protokollen.

Tokenet i klient-klientforbindelsen bestemmer, hvem der skal have lov til at downloade først.

Downloads transporteres ved hjælp af TCP. Søgninger kan transporteres ved hjælp af TCP eller UDP.

En aktiv klient har en lytteport til TCP og en anden til UDP, skønt portene ikke er afhængige af hinanden.

Protokolafgrænsere er '\ n' og '' (mellemrum). Tegnet '\' bruges som en escape-sekvens. Tilladte flugtsekvenser er "\ n" (ny linje), "\ s" (mellemrum) og "\\" (tilbageslag).

Protokollen giver mulighed for udvidelser såsom komprimering med bzip2 eller kryptering med TLS . Selvom protokollen ikke kræver, at disse udvidelser skal implementeres, kan hubber kræve dem.

Se også

Referencer

  1. ^ Fredrik Ullner (marts 2007). "ADC: Kør ned" . DC ++: Bare disse fyre, ved du det? blog . Hentet 13.12.2010 .
  2. ^ Jan Vidar Krey (august 2006). "ADC: Enkel protokol" . Jan Vidar Krey. Arkiveret fra originalen 30-01-2013 . Hentet 2006-09-23 .
  3. ^ Fredrik Ullner (marts 2006). "Power + Person = Operator" . DC ++: Bare disse fyre, ved du det? blog . Hentet 13.12.2010 .
  4. ^ Fredrik Ullner (januar 2007). "Delene af en navliste" . DC ++: Bare disse fyre, ved du det? blog . Hentet 13.12.2010 .
  5. ^ Fredrik Ullner (marts 2006). "Slots, slots, slots ..." . DC ++: Bare disse fyre, ved du det? blog . Hentet 13.12.2010 .
  6. ^ Fredrik Ullner (december 2010). "ADC Extensions - NATT - NAT traversal" . ADC-projekt . Hentet 13.12.2010 .
  7. ^ Fredrik Ullner (december 2010). "ADC - udvidelser - ADCS - symmetrisk kryptering i ADC" . ADC-projekt . Hentet 13.12.2010 .
  8. ^ En_Dator (marts 2009). "TLS og kryptering" . ADCPortal. Arkiveret fra originalen 2011-07-07 . Hentet 2009-03-01 .

eksterne links