Direkte tilkobling (protokoll) - Direct Connect (protocol)
| Del av en serie om |
| Fildeling |
|---|
 |
| Teknologier |
| Videodelingsnettsteder |
| BitTorrent -nettsteder |
| Akademisk |
| Fildelingsnettverk |
| P2P -klienter |
| Streaming -programmer |
| Anonym fildeling |
| Utvikling og samfunnsaspekter |
| Etter land eller region |
| Sammenligninger |
Direct Connect ( DC ) er et peer-til-peer-delingsprotokollen . Direct Connect -klienter kobler seg til en sentral hub og kan laste ned filer direkte fra hverandre. Advanced Direct Connect kan betraktes som en etterfølgerprotokoll.
Hubs inneholder en liste over klienter eller brukere som er koblet til dem. Brukere kan søke etter filer og laste dem ned fra andre klienter, samt chatte med andre brukere.
Historie
NeoModus ble startet som et selskap finansiert av adware "Direct Connect" av Jon Hess i november 1999 mens han gikk på videregående.
Den første tredjepartsklienten ble kalt "DClite", som aldri fullt ut støttet fildelingsaspektene ved protokollen. Hess ga ut en ny versjon av Direct Connect, som krever en enkel krypteringsnøkkel for å starte en tilkobling og låse tredjepartsklienter. Krypteringsnøkkelen ble sprukket, og forfatteren av DClite ga ut en ny versjon av DClite som er kompatibel med den nye programvaren fra NeoModus. En stund etter ble DClite omskrevet som Open Direct Connect med det formål å ha et MDI-brukergrensesnitt og bruke plug-ins for fildelingsprotokoller (lignende MLDonkey ). Open Direct Connect hadde heller ikke fullstendig støtte for hele fildelingsaspektene ved protokollen, men en port til Java gjorde det imidlertid. Senere ble andre klienter som DCTC (Direct Connect Text Client) og DC ++ populære.
DCDev -arkivet inneholder diskusjoner om protokollendringer for utvikling av DC i årene 2003–2005.
Protokoll
Direct Connect-protokollen er en tekstbasert datamaskinprotokoll, der kommandoer og deres informasjon sendes i klartekst, uten kryptering i original NeoModus-programvare ( kryptering er tilgjengelig som en protokollutvidelse). Ettersom klienter kobler seg til en sentral distribusjonskilde (navet) for informasjon, krever huben en betydelig mengde opplastingsbåndbredde tilgjengelig.
Det er ingen offisiell spesifikasjon av protokollen, noe som betyr at hver klient og nav (i tillegg til den opprinnelige NeoModus klienten og hub), har blitt tvunget til omvendt utvikling informasjonen. Som sådan er enhver protokollspesifikasjon denne artikkelen kan referere til unøyaktig og/eller ufullstendig.
Klient-server (så vel som klient-klient, hvor en klient fungerer som "server") aspekt av protokollen fastslår at serveren reagerer først når en tilkobling opprettes. For eksempel, når en klient kobles til en hubs sokkel , er huben først å svare på klienten.
Protokollen mangler en spesifisert standard tegnkoding for klienter eller hubber. Den opprinnelige klienten og huben bruker ASCII -koding i stedet for operativsystemet . Dette tillater migrering til UTF-8- koding i nyere programvare.
Port 411 er standardporten for hubber, og 412 for klient-til-klient-tilkoblinger. Hvis en av disse portene allerede er i bruk, økes portnummeret til nummeret til en ledig port er funnet for bruk. For eksempel, hvis 411, 412 og 413 er i bruk, vil port 414 bli brukt.
Hub -adresser er i følgende form: dchub: //example.com [: 411], der 411 er en valgfri port.
Det er ingen global identifikasjonsordning; i stedet identifiseres brukerne med kallenavnet sitt på en hub-til-hub-basis.
En innkommende forespørsel om en klient-klient-tilkobling kan ikke kobles til en faktisk tilkobling.
Et søkeresultat kan ikke kobles til et bestemt søk.
Evnen til å sparke eller flytte (omdirigere) en bruker til et annet knutepunkt støttes av protokollen. Hvis en bruker blir sparket, er ikke navet påkrevd å gi brukeren en spesifikk grunn, og det er ingen begrensninger for hvor en bruker kan omdirigeres. Men hvis en annen klient med makt instruerer huben om å sparke, kan denne klienten sende ut en varselmelding før han gjør det. Omdirigering av en bruker må være ledsaget av en grunn. Det er ingen HTTP -referanseekvivalent .
Hubs kan sende ut brukerkommandoer til klienter. Disse kommandoene er bare råprotokollkommandoer og brukes mest for å gjøre en bestemt oppgave enklere. Navet kan for eksempel ikke sende en brukerkommando som vil utløse standardleseren for å besøke et nettsted. Det kan imidlertid legge til kommandoen "+regler" (hvor '+' indikerer for huben at det er en kommando - dette kan variere) for å vise hubens regler.
Peer-to-peer-delen av protokollen er basert på et konsept med "slots" (ligner på antall åpne stillinger for en jobb). Disse sporene angir antall personer som kan lastes ned fra en bruker til enhver tid og som kontrolleres av klienten.
I klient-til-klient-tilkoblinger genererer partene et tilfeldig tall for å se hvem som skal få laste ned først, og klienten med det større antallet vinner.
Transport av nedlastinger og tilkobling til huben krever TCP , mens aktive søk bruker UDP .
Det er to typer moduser en bruker kan være i: enten "aktiv" eller "passiv" modus. Klienter som bruker aktiv modus kan laste ned fra alle andre på nettverket, mens klienter som bruker passiv modus bare kan laste ned fra aktive brukere. I NeoModus Direct Connect får brukere i passiv modus andre søkeresultater i passiv modus, men brukeren kan ikke laste ned noe. I DC ++ vil brukerne ikke motta disse søkeresultatene. I NeoModus Direct Connect vil alle brukere bli sendt med maksimalt fem søkeresultater per forespørsel. Hvis en bruker har søkt, vil DC ++ svare med ti søkeresultater når brukeren er i aktiv modus og fem når brukeren er i passiv modus. Passive klienter vil bli sendt søkeresultater gjennom huben, mens aktive klienter vil motta resultatene direkte.
Protokoll skilletegn er "$", "|", og U + 0020 SPACE . Protokollen har for dem (og få andre) escape -sekvens, og de fleste programvare bruker dem riktig i påloggingssekvensen (Lock to Key). Av en eller annen grunn ble rømningssekvensen ignorert av DC ++ - utviklere, og de bruker HTML -ekvivalent hvis disse tegnene skal sees av brukeren.
Det er fortsatt interesse for funksjoner som rangeringer og språkpakker. Forfatterne av DC ++ har imidlertid jobbet aktivt med en fullstendig erstatning av Direct Connect -protokollen kalt Advanced Direct Connect .
Et eksempel på en tilleggsfunksjon i protokollen, sammenlignet med den opprinnelige protokollen, er kringkasting av Tiger-Tree Hashing of shared files (TTH). Fordelene med dette inkluderer å kontrollere at en fil er lastet ned riktig, og muligheten til å finne filer uavhengig av navnene deres.
Hublister
| Navn | NMDC |
ADC |
Registrering |
CTM -deteksjon |
Trojansk oppdagelse |
Aktiv |
Unicode |
|---|---|---|---|---|---|---|---|
| dchublist.org | Ja | Ja | Nettbasert/Regserver | Ja | Ja | Ja | Ja |
| te-home.net/ | Ja | Ja | Nettbasert | Ja | Nei | Ja | |
| dchublist.ru | Ja | Nei | Ukjent | Ukjent | Nei | Ja | |
| dchublist.biz/ | Ja | Nei | Nettbasert | Ja | Nei | Ja | |
| ufo-modus.com | Ja | Nei | Regserver | Ja | Ja | Ja | Ja |
Direct Connect brukes for DDoS -angrep
Siden protokollen lar hubs omdirigere brukere til andre huber , har ondsinnede hubs omdirigert brukere til andre steder enn ekte Direct Connect -hubber, noe som effektivt forårsaket et distribuert Denial of Service -angrep. Navene kan endre IP i klient til klient tilkoblinger, og peker på et potensielt offer.
CTM Exploit dukket opp i 2006–2007, i løpet av denne perioden led hele Direct Connect -nettverket av DDoS -angrep. Situasjonen fikk utviklere til å ta sikkerhetsspørsmål mer alvorlig.
Fra februar 2009 ble det foreslått en utvidelse for klienter for at den angrepne parten skulle finne ut navet som sender de tilkoblende brukerne.
Direct Connect Network Foundation
Direct Connect Network Foundation (DCNF) er en ideell organisasjon registrert i Sverige som har som mål å forbedre DC-nettverket ved å forbedre programvare, protokoller og andre tjenester i nettverket.
Artikler og papirer
DCNF opprettholder en liste over artikler, artikler og mer dokumentasjon som gjelder DC.
