IRC/Protokół i jego odmiany

Z technicznego punktu widzenia IRC jest jednym z protokołów internetowych. Jest on nawet wpisany do typów MIME i specyfikacji URI, dzięki czemu można np. tworzyć na stronach WWW linki w postaci: irc://adres.serwera/#kanał, po których kliknięciu uruchamia się klient IRC (o ile jest poprawnie zainstalowany) i automatycznie wchodzi na dany kanał.

IRC jest o tyle dziwnym protokołem, że jego oficjalnych specyfikacji zawartych w odpowiednich dokumentach RFC (RFC 1459, RFC 2810, RFC 2811, RFC 2812, RFC 2813) nikt dokładnie nie przestrzega, tzn. aktualnie ani większość oprogramowania tworzącego serwery, ani większość klientów IRC nie stosuje się dokładnie do odpowiednich RFC, co powoduje, że w praktyce w sieciach IRC występuje wiele jego mutacji.

Protokół IRC jest otwartym protokołem tzw. warstwy aplikacyjnej TCP z możliwością stosowania też połączeń SSL. Jest to protokół typu "plaintext", tzn. podobnie jak to jest w przypadku protokołu "mail", teoretycznie można go stosować przy pomocy każdego rodzaju programu, który posiada zdolność przesyłania strumienia bajtów do serwera. Np: można by, znając na pamięć odpowiedni ciąg komend i znaków, połączyć się z serwerem IRC przy pomocy dowolnego programu do telnetu, choć oczywiście w praktyce taki sposób korzystania z IRC byłby szalenie uciążliwy. Protokół IRC opiera się na nieco tylko zmodyfikowanym zestawie znaków ASCII, co powoduje, że stosowanie znaków diakrytycznych (np. tzw. pliterek) wymaga stosowania po stronie klienta różnego rodzaju tricków, np kodowania jednego znaku diakrytycznego dwoma znakami ASCII.

O ile protokół komunikacji między serwerem i klientem jest w zasadzie zbliżony we wszystkich odmianach IRCd, poczynając od jego wersji 2.8, o tyle protokół komunikacji między serwerami różni się dość zasadniczo w różnych mutacjach IRCd. Najczęściej stosowane są TS5 (Timestamp 5), P10 i ND/CD (Nick Delay/Channel Delay), choć wiele sieci celowo implementuje protokoły zupełnie nietypowe (np: QuakeNet) i nawet nie publikuje ich dokładnej specyfikacji, aby utrudnić potencjalne ataki na serwery. Powoduje to, że różne mutacje serwerów IRC są zwykle z sobą niekompatybilne, choć niektóre z nich (np: IRC-hybrid) można przy pomocy specjalnych modułów dostosować do określonego protokołu. Istnieją też tzw. serwery mostkujące, umożliwiające w ograniczonym stopniu zestawianie sieci z różnych mutacji IRCd, pozostawiają one jednak wiele do życzenia i nie są w praktyce stosowane.

Ze względu na to, że oficjalne specyfikacje protokołu i tak nie są przestrzegane, aby omówić różnice między różnymi jego wariantami spotykanymi w istniejących sieciach, najlepiej jest opisać możliwości tzw. IRC demonów (w skrócie IRCd) - programów, które pełnią rolę serwerów IRC.

IRCd - historia i współczesność

Pierwotny demon serwerowy IRC został napisany przez Jarkko Oikarinena w 1989 r. Znany jest pod nazwą ircd. Pierwotna wersja ircd miała liczne wady, często się zawieszała i nie miała opracowanego skutecznego systemu wymiany danych między serwerami, na skutek czego niemożliwe było skonstruowanie sieci liczącej więcej niż 3 serwery. Właściwy rozwój IRC zaczął się dopiero od IRCd 2.2, który został napisany przez Markku Savela z pomocą Oikarinena. IRC z tamtych czasów był pod wieloma względami zupełnie różny od tego, który znamy obecnie. Np: kanały nie miały nazw tylko numery, a wyboru kanału dokonywano na podstawie jego topicu, który wyświetlał się po użyciu komendy list. Długość nicków była ograniczona do 3 znaków. Później, używanie 3-literowych nicków, gdy dłuższe już były dozwolone, było symbolem tego, że należy się do starej elity pionierów IRC.

Wersje od 2.3 do 2.5 były rozwijane przez ciągle spierających się z sobą właścicieli spontanicznie powstających serwerów IRC, co powodowało chaos w kodzie i ciągłe zmany kierunku rozwoju tego oprogramowania. W tym czasie istniała w zasadzie tylko jednak sieć IRC, która miała charakter zupełnie otwarty, to znaczy każdy kto dał radę postawić serwer mógł się przyłączyć nim do pozostałych. Spowodowało to jednak, że topologia sieci była całkowicie chaotyczna i wiele osób stawiało serwery tylko po to, aby uzyskać status IRCopa i móc przejąć tym sposobem jakiś kanał. W 1990 r. powstała organizacja o nazwie EFnet, która ustanowiła pierwsze reguły określające zasady przyłączania kolejnych serwerów do sieci i narzucająca rodzaj kodeksu IRCopa, zakazującego mu pewnych działań. Grupa serwerów, które znalazły się poza EFnetem utworzyła A-net (Anarchy net), która jednak z powodu kompletnego chaosu i sporów, wkrótce zanikła.

Wersja IRCd 2.5 została gruntownie uporządowana już w ramach EFnetu. Dodano w niej możliwość tworzenia kanałów posiadających nazwy tekstowe (pierwotnie jako znaku kanału używano "+" a nie "#") i wydłużono nazwy nicków do 8 znaków. Wzrastająca popularność EFnetu powodowała jednak, że sieć ta bardzo cierpiała na częste splity i trudności z zalogowaniem się do serwerów, gdyż tempo powstawania kolejnych serwerów było wolniejsze od wzrostu użytkowników.

W trakcie pracy nad IRCd 2.7 w 1992 r., część właścicieli serwerów EFnetu zdecydowała się stworzyć odrębną sieć, początkowo tylko po to aby testować w niej nowe rozwiązania techniczne, nazbyt nowatorskie aby je od razu zaimplementować w EFnecie. Testowy IRCd uzyskał nazwę icru i był od tej pory rozwijany niezależnie. Ze względu na to, że nowa sieć zyskała sporą popularność, zdecydowano się jej nie zamykać po zakończeniu prac na IRCd 2.7. Undernet do dzisiaj ma charakter sieci "dla wtajemniczonych", w której testuje się rozmaite, techniczne nowinki. M.in. to właśnie w tej sieci wprowadzono po raz pierwszy serwisy umożliwiające rejestrację kanałów i nicków, które w odróżnieniu od innych sieci nie są oparte na osobnym module dołączanym do głównego oprogramowania, lecz są weń integralnie włączone. W icru po raz pierwszy zaimplementowano też bramkę zwaną CSservice - umożliwiającą zarządzanie serwisami rejestrującym przez stronę WWW.

IRCd 2.8 był przełomową wersją demona, gdyż poza Undernetem, został on zaakceptowany przez wszystkie większe sieci IRC i prawie wszystkie późniejsze wersje IRCd wywodzą się z 2.8 i są z nią zazwyczaj wstecznie zgodne. Lista komend dopuszczalna w IRCd 2.8 stała się swoistym kanonem, który jest zaimplementowany we wszystkich klientach IRC. W ramach IRCd 2.8 wprowadzono dłuższe, 16-znakowe nazwy kanałów i nicków, przyjęto znak "#" jako wyróżnik zwykłych kanałów "!" dla kanałów szczególnie chronionych i "&" dla kanałów lokalnych - funkcjonujących tylko w ramach jednego serwera.

W 1996 nastąpił tzw. wielki split, który spowodował podzielenie się EFnetu na sieć głównie amerykańską (zwaną dalej EFnetem) oraz "resztę świata" (głównie Europę), która nazwała się IRCnetem, nawiązując tym do pierwotnej idei Oikarinena. Obie te sieci uważają się za bezpośrednie potomkinie sieci założonej przez Oikarinena i odsądzają od czci drugą stronę, choć obecnie te stare spory straciły już na ostrości. Źródłem sporu były z jednej strony kontrowersje wokół dalszego rozwoju IRCd, a z drugiej strony dyskusje na temat kodeksu dla IRCopów i ustalenia ściślejszych zasad przyłączania nowych serwerów.

W ramach IRCnetu ustalono dość ścisłe regulaminy dla właścicieli serwerów, oraz podjęto prace nad ustanowieniem "oficjalnej" specyfikacji protokołu IRC, co zaowocowało wydaniem serii dokumentów RFC, na podstawie których działa IRCnet. Pozostałe duże sieci IRC ignorują jednak RFC IRCnetu. W ramach IRCnetu ustanowiono oficjalną grupę programistów, którzy rozwijają w kontrolowany sposób IRCd, wypuszczając kolejne jego oficjalne wersje, przy czym wszyscy właściciele serwerów mają w tej sieci obowiązek unacześniania swojej wersji oprogramowania pod groźbą odłączenia. W ramach IRCnetu rozwijana jest tzw. główna linia IRCd, która jest numerowana poczynając od 2.8, a więc 2.9, 2.10, 2.11 itd. Ta linia IRCd ma ściśle zdefiniowany protokół komunikacji między serwerami, który uniemożliwia przyłączanie do nich serwerów spoza tej serii.

W EFnecie pozostawiono większą swobodę działania programistów. Powstały tam dwie odmiany IRCd 2.8 - 2.8+CS i 2.8+th, które funkcjonowały równolegle. Później, włączono do kodu 2.8-th pewne fragmenty CS i powstał w ten sposób IRCd-hybrid - który jest nadal rozwijany przez duży zespół programistów. IRCd-hybrid posiada nieco inny schemat flag niż "kanoniczny IRCd 2.8", umożliwia zaimplementowanie flagi tzw "półopa" oraz posiada możliwość dołączania modułów zmieniających protokół komunikacji między serwerami oraz dodawanie do sieci różnych wariantów serwisów dodatkowych. IRCd-hybrid, mimo że wywodzi się z EFnetu, rozwija się w oderwaniu od konkretnej sieci, próbując ustanowić ponadsieciowy standard. Jego mutacje z różnymi modułami komunikacyjnymi i serwisowym są rozwijane w ramach samych sieci. M.in:

• IRCd-rathbox - obecnie zalecany IRCd EFnetu
• IRCd-hyperion - na którym działa Freenode
• IRCd-bahamout - na którym działa DALnet

i wiele innych

Oprócz tych dwóch głównych historycznych linii rozwojowych IRCd, które wszystkie są oparte na licencji GPL, istnieją też demony IRC, które były tworzone od zera bez korzystania z kodu objętego tą licencją. Zalicza się do nich m.in:

• UnrealIRCd i QuakeIRCd - na których działa QuakeNET
• IRCX - na którym działa korporacyjna sieć IRC Microsfotu i którą Microsoft oferuje też w wolnej sprzedaży
• ConferenceRoom produkcji Webmaster Inc - komercyjna wersja IRC przeznaczona głównie do używania przez bramki WWW oparte na apletach Java, sprzedawana razem z narzędziami do tworzenia profesjonalnie wyglądających bramek IRC

i wiele innych.

Schemat rozwojowy IRCd wywodzącego się z pierwotnego demona Oikarinena można przedstawić następująco:

ircd (Oikarinen, 1989)
             |
            IRCd 2.2 (Oikarinen, Savela, 1990)
             |
            IRCDd 2.2-2.5 (liczni, spontaniczni deweloperzy, 1990-1993)
             |
            IRCDd 2.5+ (EFnet team, 1992-1993)
             |
            IRCDd 2.6-2.7 (EFNet team, 1993-1995) -> icru 2.1-2.7 (Undernet team, 1992-)
             |
            IRCd 2.8 (wersja EFNet, 1996) -> IRCd 2.8-2.11 (IRCNet, 1996-) 
             |
            IRCd 2.8+CS (Comstud, 1995) i IRCd 2.8+th (Taner, 1995)
                                    |
            IRCd-hybrid (Jon 'Rodder' Lusky i Diane 'Dianora' Bruce, 1996) 
                   |                |               |            |
               IRCd-rathbox     IRCd-hyperion  IRCd-bahamout    wiele innych...
                (EFnet)           (Freenode)    (DALnet)

IRCd a klienty

Ze względu na to, że generalnie różne mutacje IRCd stosują nieco odmienne protokoły IRC, może się zdarzyć, że Twój klient będzie miał kłopoty ze współpracą z daną siecią. Ze względu na mnogość IRCd i klientów trudno jest dokładnie podać, które klienty nie współpracują z którymi sieciami. W przypadku wyboru danego klienta do danej sieci warto w pierwszej kolejności poczytać, co o tym piszą na jej stronie WWW. Oprócz tego do niekompatybilnych klientów IRC istnieją często specjalne łatki lub skrypty, które dostosowują ich działanie do danej sieci.

Ogólnie można powiedzieć, że:

• W zasadzie wszystkie aktualne wersje popularnych klientów IRC obsługują sieci, których IRCd wywodzą się z wersji 2.8 lub są zgodne z IRCd-hybrid.
• Część popularnych klientów ma problemy z łączeniem się z Undernetem - ze względu na jego niezgodność z IRCd 2.8 - do niektórych z nich są jednak dostępne łatki.
• Niektóre rodzaje serwerów tworzonych od zera wymagają dodania do klienta specjalnie przygotowanej łatki lub skryptu, bez którego z serwerem nie da się połączyć.

Rada

pomocą w ustaleniu czy nasz klient będzie kompatybilny z daną siecią służyć może porównanie tabeli w rozdziale Klienty i tabeli na końcu tego rozdziału.

Mając już kompatybilnego z daną siecią klienta możemy mimo to natknąć się na problem z połączeniem z serwerem z przyczyn niezależnych od tej kompatybilności. Najczęściej spotykane problemy to:

• Zły nasz adres: serwer odpowiada: You are not authorized to use this server. Adres może być "zły" z powodu:
  • jest z zakresu niedozwolonego dla danego serwera (np: serwer warszawa.irc.pl akceptuje tylko adresy z centralnej i północnej Polski); rozwiązanie: poszukać właściwego dla nas serwera danej sieci (np: na jej stronie WWW)
  • adres nie ma zwrotnego DNS - niektóre serwery odrzucają połączenia z tego rodzaju adresów, aczkolwiek jest to coraz rzadsze, ze względu na rozpowszechnienie się adresów NAT i dynamicznych, które z zasady nie mają zwrotnego DNS; z naszej strony nie da się tego problemu rozwiązać, chyba że zmienimy dostarczyciela internetu lub poprosimy obecnego o przyznanie nam stałego numeru IP ze zwrotnym DNS, co jednak może być niewykonalne dla niego
  • mamy adres Ipv6 - a IRCd serwera nie potrafi rozpoznawać tego rodzaju adresów; należy albo poszukać serwera danej sieci, który radzi sobie z adresami Ipv6, albo zmienić naszego dostarczyciela internetu lub poprosić go o przyznanie nam numeru Ipv4, co może się jednak okazać dla niego niewykonalne.
• Zły adres serwera: nasz klient pisze: Unable to resolve IRC server name
  • wpisaliśmy po prostu zły adres serwera do komendy "/server"; trzeba go wpisać starannie jeszcze raz
  • serwer używa adresu Ipv6 a nasz klient lub pierwotny serwer DNS naszego dostarczyciela internetu nie umie obsługiwać tego rodzaju adresów; sprawdzić czy nasz klient obsługuje Ipv6, jeśli tak to jedyna rada zmienić dostarczyciela internetu lub poszukać innego serwera danej sieci
  • po prostu nie mamy połączenia z internetem; rozwiązanie: sprawdzić kable, sprawdzić konfigurację sieciową naszego komputera; sprawdzić czy ostatnio zapłaciliśmy rachunek za internet itp.
• Problemy z łącznością: nasz klient pisze "Connection timed out". Dzieje się tak wtedy, kiedy klient znajduje serwer, wysyła do niego prośbę o połączenie i nie dostaje żadnej odpowiedzi
  • łącze między nami i serwerem jest zbyt powolne albo nie można go skutecznie zestawić; można poszukać innego serwera sieci, który może ma lepsze połączenie z nami
  • nasz dostarczyciel internetu zablokował w ogólnej zaporze sieciowej możliwość korzystania z portów w typowym zakresie dla IRC (6660-9); należy się o to spytać administratora i ew. zmienić dostarczyciela internetu - niektóre serwery dla tego rodzaju użytkowników udostępniają nietypowe porty, o czym można zwykle przeczytać na stronie WWW danej sieci
  • sami zablokowaliśmy sobie możliwość korzystania z IRC przez np. restrykcyjne ustawienia naszej prywatnej zapory sieciowej; należy wtedy po prostu zmienić te ustawienia.

Lista znanych IRCd

IRCd	Twórcy/ Obsługiwana sieć	Źródło	Język programowania	Pierwsze wydanie	Ostatnie wydanie	Licencja udostępniana
Bahamut	DALnet	DreamForge i Hybrid	C	2002	bahamut-1.8(03)	GPL
chaosircd	Roman Senn	napisane od zera	C	2003	?	GPL
ConferenceRoom	WebMaster Incorporated	Od zera	C++	1996	ConferenceRoom/3.0	komercyjny
dancer-ircd	Freenode (obecnie porzucony)	Hybrid 6	C	?	(zastąpiony przez hyperion-ircd)	GPL
DreamForge IRCd	DALnet (obecnie porzucony)	?	C	?	(Wymieniony na bahamuta)	GPL
Microsoft Exchange	Microsoft	IRCX	C (Theorised)	1997	(~6.0.6249.0 / Service Pack 3 ?)	komercyjny
hyperion-ircd	Freenode	hybrid6-dancer-ircd	C	2002	hyperion-1.0.2(230)	GPL
ignitionServer	The Ignition Project	Pure-IRCD (VB6 version)	Visual Basic	2004	ignitionServer-0.3.6-P1.20050515	GPL
InspIRCd	ChatSpike, Brain, Craig, et al.	Od zera	C++	2002	InspIRCd-1.0.4	GPL
IRCD	IRCnet	oryginalny ircd	C	1988	irc2.11.1p1	GPL
IRCD-Hybrid	IRCD-Hybrid Development Team	irc2.8 (IRCD)	C	?	ircd-hybrid-7.2.1	?
ircd-ratbox	EFnet	2.8/hybrid	C	?	ircd-ratbox-2.1.8	GPL
ircu	Undernet Coder Committee	irc2.7 (IRCD)	C	1993	ircu2.10.12.04	GPL
IRCXpro Server	IRCXpro, Microsoft	IRCPlus	Visual Basic	?	?	komercyjny
Nefarious IRCu	Evilnet Development, AfterNET	ircu2	C	2004	u2.10.11.07+Nefarious(0.4.0)+[1.347]	GPL
PTlink IRC Server	PTlink IRC Software	ircd-hybrid6	C	2001 (v.6)	Hybrid6/PTlink6.19.6	GPL
QuakeIRCd	QuakeNet developement team	UnrealIRCd	C	1997	QuakeIRCd-1.8	GPL
UnrealIRCd	UnrealIRCd Team	DreamForge	C	1999	Unreal3.2.5	GPL
UltimateIRCd	ShadowRealm Creations	DreamForge	C	?	UltimateIRCd(Tsunami)-3.0(01)	GPL

Źródło: Wikipedia-en: Comparison_of_IRCds