2.1 Rozpoczęcie sesji (nawiązanie połączenia)
Po połączeniu się z właściwym serwerem, którego dane otrzymaliśmy z huba należy otworzyć sesję. Jest to równoznaczne z przekazaniem serwerowi informacji, żeby zaczął się nami interesować.
Protokół Tlenu umożliwia ustanowienie połączenia (sesji) zwykłej oraz szyfrowanej dwoma algorytmami: AES i RSA. Oryginalny klient Tlenu, używa oczywiście połączenia szyfrowanego, bez możliwości nawiązania nieszyfrowanej sesji.
2.1.1 Połączenie zwykłe
Nawiązanie połączenia zwykłego jest banalnie proste, wysyłamy pakiet:
<s v="9" t="06000224">Wartość atrybutu v określa wersje protokołu. Obecna wersja protokołu to 9.
W poniższej tabeli zaprezentowano rozwój wersji protokołu wraz z rozwojem programu klienta.
| v | klient |
| 3 | ~ Tlen.pl 3.50 |
| 4 | ≥ Tlen.pl 4.0 |
| 5 | ≥ Tlen.pl 4.10 |
| 6 | ≥ Tlen.pl 5.x |
| 7 | ≥ Tlen.pl 5.5.x |
| 8 | ≥ Tlen.pl 6.x |
| 9 | ≥ Tlen.pl 6.00.2.36 |
Zawartość parametru t określa wersje programu klienta użytego do połączenia, parametr ten jest opcjonalny, można go pominąć. Prawdopodobnie wprowadzono go w 6 wersji protokołu.
Ciekawy jest format "kodowania" wersji klienta.
Poszczególne składowe numeru wersji programu (major, minor, release, build) zostały zapisane w dwucyfrowej liczbie w systemie szesnastkowym, a całość pozbawiono .. Tak otrzymano 8 cyfrowy ciąg reprezentujący wersje klienta.
| t | klient |
| 05000101 | Tlen.pl 5.00.1.1 |
| 05320101 | Tlen.pl 5.50.1.1 |
| 06000023 | Tlen.pl 6.00.0.35 |
| 06000204 | Tlen.pl 6.00.2.4 |
| 0600010C | Tlen.pl 6.00.1.12 |
W tabeli powyżej przedstawiono kilka wersji, co mam nadzieję, ułatwi zrozumienie tego formatu ;)
Uwaga!
Tag s nie jest zamknięty, gdyż jest to otwarcie sesji, dopiero przy rozłączeniu (zamykaniu sesji) jest on zamykany. Wszystko, co się dzieje w obrębie tych tagów jest sednem protokołu komunikacji w sieci Tlen.pl komunikatora z serwerem.
W odpowiedzi na wysłanie pakietu rozpoczynającego sesje zwykłą, serwer odpowie nam:
<s i="456C287C" c="1">Wartość parametru i jest identyfikatorem sesji, należy go zachować, gdyż będzie nam jeszcze potrzebny, m.in. przy autoryzacji (logowaniu do sieci). Znaczenie parametru c jest nieznane, z obserwacji wynika, że oficjalny klient nie bierze go nawet pod uwagę.
W przypadku wysłania czegoś innego niż pakietu rozpoczęcia sesji, otrzymamy:
<stream:error>blad</stream:error>
</stream:stream>Warto jeszcze wspomnieć, że w przypadku wysłania niepoprawnych pakietów, czyli niepoprawnie składniowo XMLa lub jakiś innych śmieci, serwer poinformuje nas o tym pakietem:
<stream:error>Invalid XML</stream:error>i zerwie z nami połączenie.
Czemu stream a nie s?
Pewnie pozostałość po dawnych sesjach, które w pierwszych wersjach wykorzystywały jabberowy stream (patrz rozdzial Unsupported).
2.1.2 Połączenie szyfrowane
Połączenia szyfrowane zostały wprowadzone w wersji 3 protokółu. Jak już wspomniano, transmisja szyfrowana wykorzystuje dwa algorytmy: AES i RSA. Właściwe szyfrowanie opiera się na 128-bitowym algorytmie AES, uzgadnianym 512-bitowym algorytmem RSA. Więcej szczegółów na temat transmisji szyfrowanej w tlenie można znaleźć w publikacji "Połączenia szyfrowane protokołu Tlen.pl". Tutaj nie będziemy zbytnio zagłębiać się w sprawy techniczne.
Nawiązanie połączenia szyfrowanego różni się nieznacznie od połączenia zwykłego:
<s s="1" v="9" t="06000224">Jak widać, atrybut s odpowiada za rodzaj sesji, wartość 1 informuje serwer, że zamierzamy rozpocząć sesje szyfrowaną, wartość 0 lub pominiecie tego atrybutu wymusza rozpoczęcie sesji zwykłej, nieszyfrowanej, o której mówiliśmy wyżej, w poprzednim podrozdziale.
Po wysłaniu takiego pakietu, serwer odeśle nam podobny pakiet jak w połączeniu zwykłym wzbogacony o potrzebne dane do ustanowienia transmisji szyfrowanej:
<s i="456C287C" c="1" s="1" k1="10001" k2="1554a7873b24bb3e0c0101
675e018fe184fa3c9e66e80a4c33b6f2552e7e9c2b671865e1b56ce1701804c55
0cf124a8614b25e1f66c1c58a629f7be94b3650fd" k3="717765727479756961
73646667686a6b">Znaczenie i i c jest nam już znane, natomiast s informuje, że pakiet dotyczy nawiązania sesji szyfrowanej i zawiera odpowiednie dane do jej nawiązania.
Interesujące nas dane zawarte są w atrybutach k1...k3, które kolejno oznaczają: klucz publiczny RSA (e), klucz publiczny RSA (pq) i wektor inicjujący serwera (IV).
Klient generuje klucz AES i wektor inicjujący, które odsyłane są do serwera pakietem::
<cipher k1="8bf1d8db124afbcb808e0405eb4af8b27242ee0c455f31a1c6b58
0af600b0dcacbc0378cf02a72050bb784d7765ba9a41a8c7d7c622e4a8acc25a3
e1b829a70" k2="79e67e38a43961cf8d1a1377e5e9fe90"/>Parametr k1 zawiera zaszyfrowany algorytmem RSA klucz AES, a k2 wektor inicjujący klienta (nieszyfrowany).
Gdy serwer poprawnie zweryfikował dane, otrzymamy odpowiedź:
<cipher type="ok"/>Od tego momentu, dalsza transmisja danych miedzy naszym klientem a serwerem jest szyfrowana.
Klient jeszcze odeśle serwerowi zaszyfrowane, swoje "ok":
<cipher type="ok"/>W przypadku, gdy wyślemy serwerowi niepoprawne klucze, zakończy on z nami połączenie, wysyłająć pakiet zakończenia sesji.