Bezpośredni klient do klienta - Direct Client-to-Client

Direct Client-to-Client ( DCC ) (pierwotnie Direct Client Connection ) jest powiązanym z IRC podprotokołem umożliwiającym równorzędnym łączenie się za pomocą serwera IRC w celu uzgadniania w celu wymiany plików lub wykonywania nieprzekazywanych czatów. Po ustanowieniu typowa sesja DCC działa niezależnie od serwera IRC. Pierwotnie zaprojektowany do użytku z ircII , obecnie jest obsługiwany przez wielu klientów IRC . Niektórzy klienci peer-to-peer na serwerach z protokołem Napster mają również możliwość wysyłania / odbierania DCC, w tym TekNap, SunshineUN i Lopster. Odmiana protokołu DCC o nazwie SDCC (Secure Direct Client-to-Client), znana również jako DCC SCHAT, obsługuje połączenia szyfrowane . Specyfikacji RFC na wykorzystaniu DCC, nie istnieje.

Połączenia DCC można zainicjować na dwa różne sposoby:

  • Najczęstszym sposobem jest użycie CTCP do zainicjowania sesji DCC. CTCP jest wysyłany przez jednego użytkownika przez sieć IRC do innego użytkownika.
  • Innym sposobem zainicjowania sesji DCC jest bezpośrednie połączenie klienta z serwerem DCC. Korzystając z tej metody, żaden ruch nie będzie przechodził przez sieć IRC (zaangażowane strony nie muszą być podłączone do sieci IRC w celu zainicjowania połączenia DCC).

Historia

ircII był pierwszym klientem IRC, który zaimplementował protokoły CTCP i DCC. Protokół CTCP został zaimplementowany przez Michaela Sandrofa w 1990 roku dla ircII w wersji 2.1. Protokół DCC został zaimplementowany przez Troy Rollo w 1991 roku dla wersji 2.1.2, ale nigdy nie miał być przenoszony na innych klientów IRC.

Typowe aplikacje DCC

CZAT DCC

Usługa CZAT umożliwia użytkownikom rozmowę ze sobą za pośrednictwem połączenia DCC. Ruch będzie przebiegał bezpośrednio między użytkownikami, a nie przez sieć IRC. W porównaniu do normalnego wysyłania wiadomości, zmniejsza to obciążenie sieci IRC, pozwala na wysyłanie większej ilości tekstu na raz, ze względu na brak kontroli powodzi, i sprawia, że ​​komunikacja jest bezpieczniejsza, nie ujawniając wiadomości na serwerach IRC (jednak wiadomość jest nadal w postaci zwykłego tekstu ).

CHAT DCC jest zwykle inicjowany za pomocą uzgadniania CTCP . Użytkownik, który chce nawiązać połączenie, wysyła następujące CTCP do celu, gdzie ip i port to adres IP i numer portu nadawcy i są wyrażone jako liczby całkowite. protokołem jest czat dla standardowego czatu DCC. Strona odbierająca może wtedy połączyć się z podanym portem i adresem IP. DCC CHAT protocol ip port

Po ustanowieniu połączenia protokół używany do DCC CHAT jest bardzo prosty: użytkownicy wymieniają komunikaty zakończone CRLF . Komunikaty, które rozpoczynają się w ASCII 001 (kontrola-A, przedstawione poniżej, [^ a] ) i słowo mającej i są zakończone w innym ASCII 001 , są interpretowane jako emotes: [^A]ACTION waves goodbye[^A] .

Tablica DCC

Jest to rozszerzenie funkcji DCC CHAT, umożliwiające wysyłanie prostych poleceń rysowania, a także wierszy tekstu. DCC Tablica rozpoczyna się uzgadniania podobny DCC Chat, taki protokół rozmowy zastąpione wboard : . DCC CHAT wboard ip port

Po ustanowieniu połączenia dwaj klienci wymieniają komunikaty zakończone CRLF . Komunikaty zaczynające się (i opcjonalnie kończące) kodem ASCII 001 są interpretowane jako polecenia specjalne; polecenie DZIAŁANIE reprezentuje emotkę, podczas gdy inne powodują rysowanie linii na powierzchni tablicy użytkownika lub pozwalają dwóm klientom negocjować zestaw funkcji.

WYŚLIJ DCC

Usługa SEND umożliwia użytkownikom przesyłanie plików do siebie. Oryginalna specyfikacja uzgadniania nie pozwalała odbiorcy poznać całkowitego rozmiaru pliku ani wznowić przesyłania. To zmusiło klientów do wprowadzenia własnych rozszerzeń do uzgadniania, z których wiele uzyskało szerokie wsparcie.

Oryginalny handshake składał nadawcy wysyłającego następujące CTCP do odbiornika: . DCC SEND filename ip port

Podobnie jak w przypadku DCC CHAT, IP i port to adres IP i port, na którym urządzenie wysyłające będzie nasłuchiwać połączenia przychodzącego. Niektórzy klienci umieszczają nazwy plików spacjami w podwójnych cudzysłowach. Powszechną praktyką jest, aby dodać rozmiar pliku jako ostatni argument: . DCC SEND filename ip port file size

W tym momencie oryginalna specyfikacja polegała na tym, że odbiorca łączył się z podanym adresem i portem i czekał na dane lub ignorował żądanie, ale dla klientów obsługujących rozszerzenie DCC RESUME trzecią alternatywą jest poproszenie nadawcy o pominięcie części plik wysyłając CTCP odpowiadać: . DCC RESUME filename port position

Jeśli wysyłający klient obsługuje DCC RESUME, odpowie za pomocą,, a odbiornik może połączyć się z podanym adresem i portem i nasłuchiwać danych do dołączenia do już istniejącego pliku. DCC ACCEPT filename port position

Dane są przesyłane do klienta w blokach, z których każdy klient musi potwierdzić, wysyłając całkowitą liczbę odebranych bajtów w postaci 32-bitowej liczby całkowitej bajtów sieci . Spowalnia to połączenia i jest zbędne ze względu na TCP . Rozszerzenie send-ahead nieco łagodzi ten problem, nie czekając na potwierdzenia, ale ponieważ odbiorca nadal musi je wysyłać dla każdego otrzymanego bloku, na wypadek, gdyby nadawca ich oczekiwał, nie jest to całkowicie rozwiązane.

Inne rozszerzenie, TDCC lub turbo DCC, usuwa potwierdzenia, ale wymaga nieco zmodyfikowanego uzgadniania i nie jest szeroko obsługiwane. Starsze wersje TDCC zastąpiły słowo SEND w uzgadnianiu przez TSEND; późniejsze wersje używają słowa SEND, ale dołączają T po uzgodnieniu, dzięki czemu ta wersja TSEND jest kompatybilna z innymi klientami (o ile mogą przeanalizować zmodyfikowany handshake).

Exploit DCC SEND

Exploit wysyłania DCC może odnosić się do dwóch błędów, wariantu błędu przepełnienia bufora w mIRC wywołanego przez nazwy plików dłuższe niż 14 znaków oraz błędu sprawdzania poprawności danych wejściowych w niektórych routerach produkowanych przez Netgear , D-Link i Linksys , wywołanego przez użycie portu 0 . W szczególności exploit routera może zostać uruchomiony, gdy fraza „ DCC SEND ”, po której następuje co najmniej 6 znaków bez spacji lub znaków nowej linii, pojawi się w dowolnym miejscu strumienia TCP na porcie 6667, a nie tylko wtedy, gdy wykonano rzeczywiste żądanie DCC SEND.

DCC XMIT

Usługa XMIT jest zmodyfikowaną wersją DCC SEND, która pozwala na wznawianie plików i ogranicza marnotrawstwo ruchu z ACK. XMIT nie jest szeroko obsługiwany.

Uzgadnianie XMIT różni się nieco od uzgadniania WYŚLIJ. Nadawca wysyła CTCP oferując plik do odbiorcy: DCC XMIT protocol ip port[ name[ size[ MIME-type]]]

Nawiasy kwadratowe obejmują części opcjonalne. protokół jest protokołem używanym do przesyłania; tylko jasne jest obecnie zdefiniowane. W przeciwieństwie do standardowego DCC SEND, ip może występować w dodatkowej postaci standardowej notacji z kropkami dla IPv4 lub w notacji szesnastkowej lub mieszanej dla IPv6. Aby pozostawić pusty parametr wczesny, ale nadal podawać późniejszy, wcześniejszy parametr można określić jako - . Jeśli odbiornik nie implementuje protokół używany, to odesłać odpowiedź CTCP formatu: . ERRMSG DCC CHAT protocol unavailable

CZAT służy tutaj do zachowania zgodności z komunikatami o błędach wysyłanymi przez rozszerzony CHAT DCC. Jeżeli odbiorca odmawia przeniesienia, wysyła następującą odpowiedź CTCP: . ERRMSG DCC CHAT protocol declined

Inne błędy są zgłaszane w ten sam sposób. Jeśli odbiorca chce i może odebrać plik, połączy się z podanym adresem i portem. To, co się wtedy stanie, zależy od używanego protokołu.

W przypadku czystego protokołu, serwer XMIT po odebraniu połączenia wyśle ​​32-bitowy time t w sieciowej kolejności bajtów , reprezentujący czas modyfikacji pliku. Przypuszczalnie na podstawie czasu modyfikacji pliku lokalnego klient wyśle ​​kolejną kolejność bajtów sieci long , przesunięcie, do którego serwer powinien dążyć podczas wysyłania pliku. Powinno to być ustawione na zero, jeśli potrzebny jest cały plik, lub rozmiar pliku lokalnego, jeśli klient chce wznowić poprzednie pobieranie.

Chociaż XMIT jest szybszy niż SEND, ma jedno z tych samych ograniczeń, ponieważ nie można stwierdzić, jak duży jest plik, chyba że jego rozmiar jest określony w negocjacjach CTCP lub znany wcześniej. Ponadto nie jest możliwe wznowienie pliku po przekroczeniu znacznika dwóch gigabajtów ze względu na 32-bitowe przesunięcie.

Pasywne DCC

W normalnym połączeniu DCC inicjator działa jako serwer , a celem jest klient . Ze względu na powszechne zapory ogniowe i zmniejszenie przejrzystości od końca do końca z powodu NAT inicjator może nie być w stanie działać jako serwer. Opracowano różne sposoby proszenia celu, aby działał jako serwer:

Serwer DCC

To rozszerzenie normalnego wysyłania i czatu DCC zostało wprowadzone przez klienta IRC mIRC . DCC Server ma umiarkowane wsparcie, ale nie jest standardem na wszystkich klientach (zobacz Porównanie klientów Internet Relay Chat ).

Pozwala na zainicjowanie połączenia DCC na podstawie adresu IP, bez konieczności korzystania z serwera IRC. Jest to realizowane przez klienta odbierającego działającego jako serwer (stąd nazwa) nasłuchujący (zwykle na porcie 59) uzgadniania od nadawcy.

W przypadku CZATU inicjator wysyła . Cel następnie odpowiada , a reszta przebiega zgodnie ze standardowym protokołem DCC CHAT. 1000 initiator nick1000 target nick

W przypadku WYŚLIJ inicjator wysyła . Cel odpowiada , gdzie pozycja wznowienia jest przesunięciem w pliku, od którego ma rozpocząć się. Stąd transfer przebiega jak normalne WYSYŁANIE DCC. 1200 initiator nick filesize filename1210 target nick resume position

Serwer DCC obsługuje również serwery plików w stylu mIRC i DCC GET.

RDCC

Serwer DCC nie umożliwia określenia portu, który ma być używany, więc należy to negocjować ręcznie, co nie zawsze jest możliwe, ponieważ jedna ze stron może nie być człowiekiem. RDCC to mechanizm uzgadniania dla serwera DCC, który oprócz portu zapewnia również adres IP serwera, którego klient może nie być w stanie znaleźć w inny sposób z powodu maskowania hostów. Nie jest szeroko obsługiwany.

Inicjator żąda portu, na którym nasłuchuje cel, wysyłając zapytanie CTCP , gdzie funkcja to c dla rozmowy, s dla wysyłania lub f dla serwera plików. RDCC function comment

Cel może następnie odpowiedzieć CTCP, podając,, gdzie ip i port mają takie same znaczenie jak dla normalnego DCC SEND i CHAT. Następnie inicjator łączy się z adresem IP i portem , po czym następuje uzgadnianie serwera DCC. RDCC 0 ip port

DCC REVERSE

W przeciwieństwie do serwera DCC, gdzie uzgadnianie jest obsługiwane przez bezpośrednie połączenie IP, DCC REVERSE ma normalne uzgadnianie CTCP, podobne do używanego przez DCC SEND. Nie jest to powszechnie stosowane. Nadawca oferuje plik do odbiornika poprzez wysłanie wiadomości CTCP: . klucz jest ciągiem znaków ASCII o długości 1–50 znaków z zakresu 33–126 i pełni rolę identyfikatora transferu. DCC REVERSE filename filesize key

Jeśli odbiorca zaakceptuje, wysyła odpowiedź CTCP, DCC REVERSE key start ip port

Tutaj początek to pozycja w pliku, od której ma rozpocząć się wysyłanie, ip to adres IP odbiorcy w standardowej notacji kropkowej dla IPv4 lub notacji szesnastkowej dla IPv6 . Następnie nadawca łączy się z adresem IP i portem wskazanym przez odbiorcę, po czym następuje normalne WYSYŁANIE DCC. Zarówno nadawca i odbiorca może anulować handshake wysyłając odpowiedź CTCP, . DCC REJECT REVERSE key

DCC RSEND

To jest alternatywa klienta KVIrc dla DCC REVERSE. Nadawca oferuje plik wysyłając CTCP: . Odbiorca może następnie zaakceptować, odpowiadając CTCP za pomocą,, a nadawca łączy się z odbiorcą i wysyła tak, jak podczas normalnego wysyłania DCC. DCC RSEND filename filesizeDCC RECV filename ip port start

Reverse / Firewall DCC

Ten pasywny mechanizm DCC jest obsługiwany przez co najmniej mIRC , Visual IRC , XChat , KVIrc , DMDirc , Klient , Konversation i PhibianIRC . Nadawca oferuje plik wysyłając wiadomość CTCP, . ip to adres IP nadawcy w sieciowej kolejności bajtów, wyrażony jako pojedyncza liczba całkowita (jak w standardowym DCC). Liczba 0 jest wysyłana zamiast prawidłowego portu, sygnalizując, że jest to żądanie Reverse DCC. token to unikalna liczba całkowita; jeśli TSEND jest używany (przez klienta, który go obsługuje), litera T jest dołączana do tokena, informując odbiorcę, że nie musi wysyłać potwierdzeń. DCC SEND filename ip 0 filesize token

Odbiornik może zaakceptować plik otwierając gniazdo słuchanie i reagowanie z komunikatem CTCP, . Jest to identyczne z oryginalnym komunikatem Reverse DCC, z wyjątkiem adresu IP i portu, które identyfikują gniazdo, w którym nasłuchuje odbiornik. token jest taki sam jak w pierwotnym żądaniu, informując nadawcę, które żądanie zostało przyjęte. (Ponieważ ten komunikat ma ten sam format, co zwykłe żądanie wysyłania DCC, niektóre serwery filtrujące żądania DCC mogą wymagać od nadawcy dodania odbiorcy do listy „DCC allow”). DCC SEND filename ip port filesize token

Następnie nadawca łączy się z gniazdem odbiorcy, wysyła zawartość pliku i czeka, aż odbiorca zamknie gniazdo po zakończeniu tworzenia pliku.

Gdy używane jest rozszerzenie RESUME do protokołu SEND, sekwencja poleceń staje się (z >> wskazującym wiadomość wychodzącą po stronie inicjującej i << odpowiedzią przez partnera):

>> DCC SEND filename ip 0 filesize token
<< DCC RESUME filename 0 position token
>> DCC ACCEPT filename 0 position token
<< DCC SEND filename peer-ip port filesize token

Po czym protokół przebiega normalnie (czyli nadawca łączy się z gniazdem odbiorcy).

Serwery plików (FSERV)

DCC fserve lub serwer plików, pozwala na przeglądanie użytkownika, czytać i pobierania plików znajdujących się na serwerze DCC.

Zwykle jest to realizowane za pomocą sesji DCC CHAT (która przedstawia użytkownikowi wiersz poleceń ) lub specjalnych poleceń CTCP w celu zażądania pliku. Pliki są wysyłane przez DCC SEND lub DCC XMIT. Istnieje wiele implementacji serwerów plików DCC, wśród nich jest komenda FSERV w popularnym kliencie mIRC .

Zobacz też

Bibliografia

Linki zewnętrzne