Protokol klient-klient - Client-to-client protocol - Wikipedia

Protokol klient-klient (CTCP) je speciální typ komunikace mezi Internet Relay Chat (IRC) klienty.

CTCP je běžný protokol implementovaný většinou hlavních klientů IRC, který se dnes používá.^{[Citace je zapotřebí ]} CTCP rozšiřuje původní protokol IRC tím, že umožňuje uživatelům dotazovat se na jiné klienty nebo kanály, což způsobí, že všichni klienti v kanálu odpoví CTCP, aby získali konkrétní informace. CTCP lze navíc použít ke kódování zpráv, které by surový protokol IRC neumožňoval odesílat přes odkaz, například zprávy obsahující nové řádky nebo byte hodnota 0 (NULL). CTCP nevytváří přímé spojení mezi klienty; běžně se však používá k vyjednávání DCC připojení.

CTCP umožňuje uživatelům dotazovat se vzdáleného klienta na verzi klienta, kterou používají (přes VERZE CTCP) nebo čas (přes ČAS CTCP), mimo jiné. Používá se také k implementaci příkazu / me (přes AKCE CTCP).

Dějiny

ircII byl prvním klientem IRC, který implementoval protokoly CTCP a DCC.^[1] Protokol CTCP implementoval Michael Sandrof v roce 1990 pro ircII verze 2.1,^[2] zatímco protokol DCC implementoval Troy Rollo v roce 1991 pro verzi 2.1.2.^[3]

Struktura

Zpráva CTCP je implementována jako PRIVMSG nebo OZNÁMENÍ kde jsou první a poslední znaky zprávy ASCII hodnota 0x01. Navíc jsou uniknuty znaky, které by nebyly povoleny v protokolu IRC. Protože a OZNÁMENÍ protože standard by neměl generovat odpověď, zprávy CTCP jsou odesílány jako PRIVMSG a odpověď je implementována pomocí OZNÁMENÍ místo a PRIVMSG.

CTCP dotaz se inicializuje u většiny klientů následovně:

CTCP   

Kde <target> je cílová přezdívka nebo kanál, <command> je příkaz CTCP (např. VERZE), a <arguments> jsou další informace, které mají být zaslány <target>.

Běžné příkazy CTCP

Příkazy a odpovědi CTCP jsou specifické pro klienta; v závislosti na klientovi IRC nemusí některé z následujících příkazů CTCP vyvolat odpověď nebo budou formátovány odlišně od toho, co je zde zobrazeno.

VERZE

A VERZE CTCP požadavek vrátí jméno a verzi klienta IRC, který cíl používá, a v některých případech technické informace, jako například operační systém, rychlost hodin, Výrobce CPU a Architektura CPU /instrukční sada.

Ukázka odpovědi na a VERZE CTCP požadavek na cíl, který používá HexChat klient (a Vidlička XChat) je:

VERZE HexChat 2.9.1 [x86] / Windows 8 [1,46 GHz]

ČAS

A ČAS CTCP žádost vrátí místní čas cílového počítače. V závislosti na klientovi IRC může odpověď obsahovat: datum, čas (buď v 12hodinový formát nebo 24hodinový formát ), rok 2012) a někdy i časové pásmo (např. EST ).

Ukázka odpovědi na a ČAS CTCP požadavek na cíl, který používá ChatZilla klient je:

ČAS Pá 23. listopadu 2012 19:26:42 EST

PING

A CTCP PING žádost určí rychlost ping která přímo existuje mezi dvěma klienty (tj. diskontování serveru). The CTCP PING příkaz funguje odesláním (často) celé číslo argument (A časové razítko ) cílovému klientovi, cílový klient poté odpoví zadáním přesně stejného číselného parametru. The rozdíl mezi původním časovým razítkem a aktuálním časovým razítkem se vypočítá, přičemž výsledek se zobrazí uživateli, který zahájil CTCP PING. Více často než ne, časové razítko, které využívá milisekundy se používá kvůli většině uživatelů s širokopásmové připojení Připojení k internetu s pingem do 1 sekundy.

Vzorek CTCP PING žádost o cíl <nickname> z XChat klient je:

CTCP PING 23152511

Podobně je ukázkový výstup generovaný z rozdílu (viz výše):

Ping odpověď od : 0,53 sekundy

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

a jsou hodnoty odesílatele a jsou vyjádřeny jako celá čísla. je „chat“ pro standardní DCC CHAT. Přijímající strana se poté může připojit k danému portu a adrese.

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 (control-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ůsobují vykreslování čar na povrchu tabule uživatele nebo umožňují 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 a adresa IP a port, kde bude odesílající zařízení naslouchat příchozímu připojení. Někteří klienti uzavírají názvy souborů mezerami do uvozovek. Je běžnou praxí přidat velikost souboru jako poslední argument:

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ů^[4] 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.^[5][6] 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. je protokol použít k převodu; v současné době je definováno pouze „jasné“. Na rozdíl od standardního DCC SEND může být v dalších formách standardní tečkované notace pro IPv4 nebo hexadecimální nebo smíšené notace pro IPv6. Chcete-li ponechat časný parametr prázdný, ale přesto dodat pozdější, lze dřívější zadat jako „-“. Pokud přijímač neimplementuje použitý protokol, pošle zpět odpověď CTCP ve formátu:

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č ochoten a schopen 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 jeho velikost není uvedena v CTCP vyjednávání nebo předem známé. Kromě toho 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 pak 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 je posun v souboru, od kterého se má začít. Odtud pokračuje přenos jako normální DCC SEND.

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 je 'c' pro chat, 's' pro odesílání a 'f' pro souborový server.

Cíl pak může CTCP odpovědět:

RDCC 0

kde a mají stejný význam jako pro normální DCC SEND a CHAT. Poté se iniciátor připojí k ip a portu a následuje handshake serveru DCC.

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

je řetězec o délce 1 až 50 znaků ASCII znaků v rozsahu 33 až 126 a slouží jako identifikátor přenosu.

Pokud přijímač přijme, odešle odpověď CTCP:

DCC REVERSE

Zde je pozice v souboru, ze kterého se má začít odesílat, je IP adresa přijímače standardně tečkovaný zápis pro IPv4 nebo hexadecimální notace pro IPv6. Odesílatel se poté připojí k adrese IP a portu označenému přijímačem a následuje normální DCC SEND. Odesílatel i příjemce mohou handshake zrušit odesláním odpovědi CTCP:

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

je IP adresa odesílatele v pořadí bajtů sítě, vyjádřeno jako jedno celé číslo (jako ve standardním DCC). Místo platného portu se odesílá číslo 0, což signalizuje, že se jedná o požadavek reverzního DCC. je jedinečné celé číslo; pokud je používán TSEND (klient, který jej podporuje), je k tokenu připojeno písmeno „T“, které informuje příjemce, že nemusí odesílat potvrzení.

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 a identifikující soket, kde přijímač poslouchá. je stejný jako v původním požadavku, což odesílateli sdělí, který požadavek je přijímán. (Protože tato zpráva má stejný formát jako běžný požadavek na odeslání DCC, některé servery, které filtrují požadavky DCC, mohou vyžadovat, aby odesílatel přidal příjemce do svého seznamu „Povolit DCC“.)

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é

• Internet Relay Chat (IRC)
• IRC klient
• Porovnání klientů Internet Relay Chat
• DCC (Přímý klient-klient)

Reference

externí odkazy

• Podrobnosti CTCP