Přímý klient-klient - Direct Client-to-Client
![]() | Tento článek má několik problémů. Prosím pomozte vylepši to nebo diskutovat o těchto problémech na internetu diskusní stránka. (Zjistěte, jak a kdy tyto zprávy ze šablony odebrat) (Zjistěte, jak a kdy odstranit tuto zprávu šablony)
|
Přímý klient-klient (DCC) (původně Přímé připojení klienta[1][2][3]) je IRC související sub-protokol umožňující vrstevníci propojit pomocí serveru IRC pro potřesení rukou za účelem výměny souborů nebo chatování bez přenosu. Po vytvoření se typická relace DCC spustí nezávisle na serveru IRC. Původně navrženo pro použití s ircII nyní je podporován mnoha IRC klienti. Někteří klienti typu peer-to-peer na serverech s protokolem napster mají také funkci DCC send / get, včetně TekNap, SunshineUN a Lopster. Varianta protokolu DCC s názvem SDCC (Secure Direct Client-to-Client), známá také jako DCC SCHAT podporuje šifrované připojení. An Specifikace RFC o použití DCC neexistuje.
Připojení DCC lze zahájit dvěma různými způsoby:
- Nejběžnějším způsobem je použití CTCP zahájit relaci DCC. CTCP je odeslán od jednoho uživatele přes síť IRC jinému uživateli.
- Dalším způsobem, jak zahájit relaci DCC, je připojení klienta přímo k serveru DCC. Při použití této metody nebude přes síť IRC procházet žádný provoz (zúčastněné strany nemusí být připojeny k síti IRC, aby bylo možné zahájit připojení DCC).
Dějiny
ircII byl prvním klientem IRC, který implementoval protokoly CTCP a DCC.[4] Protokol CTCP implementoval Michael Sandrof v roce 1990 pro ircII verze 2.1.[5] Protokol DCC implementoval Troy Rollo v roce 1991 pro verzi 2.1.2,[6] ale nikdy nebyl zamýšlen jako přenosný pro ostatní klienty IRC.[7][8]
Běžné aplikace DCC
DCC CHAT
Služba CHAT umožňuje uživatelům chatovat mezi sebou přes připojení DCC. Provoz bude probíhat přímo mezi uživateli, nikoli přes síť IRC. Ve srovnání s normálním odesíláním zpráv to snižuje zatížení sítě IRC, umožňuje odesílání většího množství textu najednou kvůli nedostatečné kontrole zaplavení a zajišťuje bezpečnější komunikaci tím, že zprávu nevystavuje serverům IRC (nicméně zpráva je stále v prostý text ).
DCC CHAT se obvykle spouští pomocí CTCP potřesení rukou. Uživatel, který si přeje navázat spojení, odešle do cíle následující CTCP:
DCC CHAT
Jakmile je navázáno připojení, protokol používaný pro DCC CHAT je velmi jednoduchý: uživatelé si vyměňují CRLF ukončené zprávy. Zprávy, které začínají na ASCII 001 (kontrola-A, níže znázorněno ^ A) a slovo „AKCE“ a jsou ukončeny jiným ASCII 001, jsou interpretovány jako emoce:
^ AAKCE mává na rozloučenou^ A
Tabule DCC
Jedná se o rozšíření DCC CHAT, které umožňuje odesílání jednoduchých příkazů kreslení i řádků textu. Tabule DCC je zahájena metodou handshake podobnou DCC CHAT, přičemž protokol „chat“ je nahrazen „wboard“:
DCC CHAT wboard
Jakmile je připojení navázáno, oba klienti se vymění CRLF ukončené zprávy. Zprávy, které začínají (a volitelně končí) ASCII 001, jsou interpretovány jako speciální příkazy; příkaz AKCE představuje emotu, zatímco jiné způsobí vykreslení čar na povrchu tabule uživatele nebo umožní dvěma klientům vyjednat sadu funkcí.
DCC ODESLAT
Služba SEND umožňuje uživatelům posílat soubory navzájem. Původní specifikace handshake neumožňovala přijímači znát celkovou velikost souboru ani obnovit přenos. To přimělo klienty zavést vlastní rozšíření handshake, z nichž mnohé jsou široce podporovány.
Původní handshake spočíval v tom, že odesílatel poslal následující CTCP do přijímače:
DCC SEND
Stejně jako u DCC CHAT jsou
DCC SEND
V tomto okamžiku měla původní specifikace přijímač buď připojit se k dané adrese a portu a počkat na data, nebo požadavek ignorovat, ale pro klienty podporující rozšíření DCC RESUME je třetí alternativou požádat odesílatele, aby přeskočil část soubor zasláním odpovědi CTCP:
DCC RESUME
Pokud odesílající klient podporuje DCC RESUME, odpoví:
DCC ACCEPT
a přijímač se může připojit k dané adrese a portu a poslouchat data, aby se připojil k již existujícímu souboru.
Data jsou klientovi zasílána v blocích, přičemž každý z nich musí klient potvrdit zasláním celkového počtu přijatých bajtů ve formě 32-bit pořadí bajtů v síti celé číslo. To zpomaluje připojení a je nadbytečné kvůli TCP. Rozšíření send-ahead tento problém poněkud zmírňuje tím, že nečeká na potvrzení, ale protože je příjemce stále musí posílat pro každý blok, který obdrží, v případě, že je odesílatel očekává, není zcela vyřešen.
Další rozšíření, TDCC nebo turbo DCC, odstraňuje potvrzení, ale vyžaduje mírně upravený handshake a není široce podporován. Starší verze TDCC nahradily slovo SEND v potřesení rukou TSEND; novější verze používají slovo SEND, ale po handshake přidávají „T“, čímž je tato verze TSEND kompatibilní s ostatními klienty (pokud mohou analyzovat upravené handshake).
DCC SEND exploit
Exploze odesílání DCC může odkazovat na dvě chyby, variantu přetečení zásobníku chyba v mIRC spuštěno názvy souborů delšími než 14 znaků[9] a chyba ověření vstupu v některých směrovačích vyráběných společností Netgear, D-Link a Linksys, vyvolané použitím portu 0.[10][11] Zejména zneužití routeru může být spuštěno, když fráze „DCC ODESLAT'následovaný alespoň 6 znaky bez mezer nebo nových řádků se objeví kdekoli v a TCP stream na portu 6667, nejen když byl podán skutečný požadavek DCC SEND.
DCC XMIT
Služba XMIT je upravená verze DCC SEND, která umožňuje obnovení souborů a omezení zbytečného provozu z ACK longů. XMIT není široce podporován.
Handshake XMIT se trochu liší od handshake SEND. Odesílatel odešle CTCP nabídka souboru přijímači:
DCC XMIT
[ [ [ ]]]]
Hranaté závorky zde obsahují volitelné součásti.
ERRMSG DCC CHAT
není k dispozici
CHAT se zde používá k udržení kompatibility s chybovými zprávami odeslanými rozšířeným DCC CHAT. Pokud přijímač odmítne přenos, odešle následující odpověď CTCP:
ERRMSG DCC CHAT
byl odmítnut
Ostatní chyby jsou hlášeny stejným způsobem. Pokud je přijímač ochotný a schopný přijímat soubor, připojí se k dané adrese a portu. Co se potom stane, závisí na použitém protokolu.
V případě „jasného“ protokolu server XMIT po přijetí připojení odešle 32bitový protokol čas t v pořadí bajtů v síti, představující čas úpravy souboru. Pravděpodobně na základě doby modifikace místního souboru klient poté odešle další pořadí bytů v síti dlouho, posun, o který by se měl server snažit při odesílání souboru. To by mělo být nastaveno na nulu, pokud je požadován celý soubor, nebo velikost místního souboru, pokud si klient přeje obnovit předchozí stahování.
I když je rychlejší než SEND, XMIT má jedno ze stejných omezení v tom, že není možné zjistit, jak velký je soubor, pokud není jeho velikost uvedena v CTCP vyjednávání nebo předem známé. Dále nemůžete obnovit soubor za značku dvou gigabajtů kvůli 32bitovému posunu.
Pasivní DCC
Při normálním připojení DCC iniciátor funguje jako serveru a cílem je klient. Z důvodu rozšířeného firewalling a snížení end-to-end transparentnosti z důvodu NAT, iniciátor nemusí být schopen fungovat jako server. Byly navrženy různé způsoby, jak požádat cíl, aby jednal jako server:
DCC Server
Toto rozšíření na normální DCC SEND a CHAT bylo zavedeno klientem IRC mIRC. Server DCC má střední podporu, ale není standardní u všech klientů (viz Porovnání klientů Internet Relay Chat ).
Umožňuje zahájení DCC připojení pomocí IP adresy, bez nutnosti IRC serveru. Toho je dosaženo přijímajícím klientem, který funguje jako server (odtud název) a poslouchá (obvykle na portu 59) handshake od odesílatele.
U CHATu iniciátor odešle:
1000
Cíl poté odpoví:
1000
a zbytek probíhá podle standardního protokolu DCC CHAT.
Pro ODESLÁNÍ iniciátor odešle:
1200
Cíl odpovídá:
1210
kde
Server DCC také podporuje souborové servery ve stylu mIRC a DCC GET.
RDCC
Server DCC neposkytuje žádný způsob, jak specifikovat port, který se má použít, takže to musí být sjednáno ručně, což není vždy možné, protože jednou ze stran nemusí být člověk. RDCC je mechanismus handshake pro DCC Server, který kromě portu poskytuje také IP adresu serveru, kterou by klient kvůli maskování hostitele nemusel najít jinak. Není široce podporován.
Iniciátor požádá o port, na kterém cíl naslouchá, odesláním dotazu CTCP:
RDCC
kde
Cíl pak může CTCP odpovědět:
RDCC 0
kde
DCC REVERSE
Na rozdíl od DCC Serveru, kde je handshake zpracováván přes přímé připojení IP, má DCC REVERSE normální CTCP handshake, podobný tomu, který používá DCC SEND. To není široce implementováno. Odesílatel nabídne příjemci soubor zasláním zprávy CTCP:
DCC REVERSE
Pokud přijímač přijme, odešle odpověď CTCP:
DCC REVERSE
Zde
DCC REJECT REVERSE
DCC RSEND
Toto je alternativa klienta KVIrc k DCC REVERSE. Odesílatel nabízí soubor zasláním CTCP:
DCC RSEND
Přijímač poté může CTCP přijmout odpověď s:
DCC RECV
a odesílatel se připojí k přijímači a odešle jako během normálního DCC SEND.
Reverzní / Firewall DCC
Tento pasivní mechanismus DCC je podporován minimálně mIRC, Vizuální IRC, XChat, KVIrc, DMDirc, Klient, Konverzace, a PhibianIRC. Odesílatel nabídne soubor zasláním zprávy CTCP:
DCC SEND
0
Přijímač může přijmout soubor otevřením naslouchací zásuvky a odpovědí zprávou CTCP:
DCC SEND
Toto je identické s původní zprávou Reverse DCC, s výjimkou
Odesílatel se poté připojí k zásuvce přijímače, odešle obsah souboru a čeká, až přijímač po dokončení souboru soket zavře.
Když se použije rozšíření RESUME na protokol SEND, stane se posloupnost příkazů (s '>>' označující odchozí zprávu na iniciační straně a '<<' odpovědí peer):
>> DCC SEND
0 << DCC RESUME <filename> 0 <position> <token>
>> DCC ACCEPT
0 << DCC SEND <filename> <peer-ip> <port> <filesize> <token>
Poté protokol pokračuje jako obvykle (tj. Odesílatel se připojí k zásuvce přijímače).
Souborové servery (FSERV)
DCC fservenebo souborový server umožňuje uživateli procházet, číst a stahovat soubory umístěné na serveru DCC.
Obvykle se to provádí pomocí relace DCC CHAT (která uživateli poskytuje příkazový řádek) nebo speciální CTCP příkazy k vyžádání souboru. Soubory jsou odesílány prostřednictvím DCC SEND nebo DCC XMIT. Existuje mnoho implementací souborových serverů DCC, mezi nimi je v populárním příkazu FSERV mIRC klient.
Viz také
Reference
- ^ https://www.troy.rollo.name/opensource.html
- ^ http://www.kvirc.net/doc/doc_dcc_connection.html
- ^ http://www.irchelp.org/protocol/ctcpspec.html
- ^ Piccard, Paul; Brian Baskin; George Spillman; Marcus Sachs (1. května 2005). "Sítě a zabezpečení IRC". Zabezpečení aplikací IM a P2P pro podnik (1. vyd.). Synchronizace. str. 386. ISBN 1-59749-017-2.
Autoři softwarového balíčku ircII původně propagovali přenosy souborů přes IRC.
- ^ Podívejte se na soubory „NOTES“ a „source / ctcp.c“, které jsou součástí ircii-2.1.4e.tar.gz[trvalý mrtvý odkaz ]
- ^ Podívejte se na soubory „UPDATES“ a „source / dcc.c“, které jsou součástí ircii-2.1.4e.tar.gz[trvalý mrtvý odkaz ]
- ^ Troy Rollo (20. ledna 1993). „/ dcc“. Diskusní skupina: alt.irc. Usenet: [email protected]. Citováno 10. listopadu 2010.
- ^ Rollo, Troy. "Popis protokolu DCC". irchelp.org. Citováno 10. listopadu 2010.
První poznámka, kterou bych měl udělat, je, že protokol DCC nebyl nikdy navržen tak, aby byl přenosný pro jiné klienty než IRCII. Nepřebírám žádnou odpovědnost za to, že je obtížné jej implementovat pro ostatní klienty.
- ^ „Informace o zneužití SecurityFocus“.
- ^ "'Chyba zabezpečení DCC Send na směrovačích Netgear “.
- ^ "'Chyba zabezpečení DCC Send na směrovačích Linksys ".
externí odkazy
- Popis protokolu DCC (poznámka: Většina klientů a sítí IRC implementovala rozšíření protokolu DCC. Dnes běžně používaný DCC se od toho, co tento dokument popisuje, vyvinul docela dost.)
- Vyjednávání a připojení DCC
- Popis protokolu Turbo DCC
- Popis protokolu DCC Whiteboard