Pisząc grę inter­ne­tową trzeba zasta­no­wić się nad spo­so­bem komu­ni­ka­cji mię­dzy gra­czami oraz bazą danych. W przy­padku apli­ka­cji prze­glą­dar­ko­wych dużego wyboru nie ma. Prak­tycz­nie wszyst­kie gry wyko­rzy­stują tech­no­lo­gię AJAX. Jak to działa w prak­tyce? Nie za dobrze. Spró­bujmy stwo­rzyć coś dużo bar­dziej wydajniejszego.

Spo­sób dzia­ła­nia tech­no­logi AJAX

AJAX to roz­wią­za­nie jed­no­stronne. Klient prosi ser­wer o pewne infor­ma­cje, a ten je wysyła użyt­kow­ni­kowi. Ser­wer nie posiada dokład­nych infor­ma­cji na temat ilo­ści aktu­al­nie połą­czo­nych użyt­kow­ni­ków oraz nie może wysłać do żadnego z nich samo­dziel­nie żadnej informacji(tj. może jedy­nie odpo­wia­dać na ich zapytania).

Kocham robić te fajne obrazki i choć nie mają one niczego wspól­nego z UML-em mam nadzieję, że jesteś w sta­nie je odczytywać

Prze­ana­li­zujmy przy­kład czatu inter­ne­to­wego w któ­rym mamy trzech użytkowników(Client1, Client2, Client3). Pierw­szy z nich chce wysłać infor­ma­cję do trze­ciego. Wygląda to następująco:

• (1) Client1 pyta ser­wer czy są jakieś wia­do­mo­ści do niego. Ser­wer zwraca infor­ma­cję o ich braku.
• (2) Client2 pyta ser­wer czy są jakieś wia­do­mo­ści do niego. Ser­wer zwraca infor­ma­cję o ich braku.
• (3) Client3 pyta ser­wer czy są jakieś wia­do­mo­ści do niego. Ser­wer zwraca infor­ma­cję o ich braku.
• (4) Client1 wysyła do ser­wera wia­do­mość prze­zna­czoną dla użyt­kow­nika Client3. Ser­wer zwraca infor­ma­cję o przy­ję­ciu danych.
• (4,5) Ser­wer zapi­suje wia­do­mość do swo­jego bufora(w tym przy­kła­dzie bazy danych)
• (5) Client2 pyta ser­wer czy są jakieś wia­do­mo­ści do niego. Ser­wer zwraca infor­ma­cję o ich braku.
• (6) Client3 pyta ser­wer czy są jakieś wia­do­mo­ści do niego.
• (6,5) Ser­wer odczy­tuje z bazy danych wia­do­mość oraz zwraca ją użytkownikowi.
• (7) Client1 pyta ser­wer czy są jakieś wia­do­mo­ści do niego. Ser­wer zwraca infor­ma­cję o ich braku.
• (8) Client2 pyta ser­wer czy są jakieś wia­do­mo­ści do niego. Ser­wer zwraca infor­ma­cję o ich braku.
• (9) Client3 pyta ser­wer czy są jakieś wia­do­mo­ści do niego. Ser­wer zwraca infor­ma­cję o ich braku.
• (…)

Jak widać wyko­ny­wa­nych jest wiele nie­po­trzeb­nych zapy­tań. Każdy z klien­tów musi stale wysłać zapy­ta­nie do ser­wera co w przy­padku małego czasu może powo­do­wać spore zuży­cie pro­ce­sora ser­wera. W sytu­acji, gdy czas będzie więk­szy w grze poja­wią się lagi. Jak ten pro­blem roz­wią­zuje się w „nor­mal­nych“ grach inter­ne­to­wych? Uży­wane są gniazda.

Jak dzia­łają gniazda

Sze­ro­kie linie ozna­czają nasłu­chi­wa­nie ser­wera oraz klientów

Każdy z klien­tów musi usta­no­wić połą­cze­nie z ser­we­rem. Ser­wer dla każ­dego z nich two­rzy gniazdo za pomocą któ­rego w dowol­nym momen­cie może wysłać infor­ma­cję do jed­nego z użytkowników.

Wygląda to tak:

• (0) Client1, Client2, Client3 nawią­zują połą­cze­nie z serwerem(tworzone są gniazda)
• (1) Client1 wysyła wia­do­mość do ser­wera (ser­wer zwraca komu­ni­kat o sukcesie)
• (2) Ser­wer odnaj­duje gniazdo trze­ciego użytkownika
• (3) Ser­wer wysyła wia­do­mość do Client3

W odróż­nie­niu do tech­no­logi AJAX w tym przy­padku nasz ser­wer napi­sany w php musi cią­glę nasłu­chi­wać, a więc pro­ces tego skryptu musi być cały czas uru­cho­miony. W tym celu two­rzy się pętlę nie­skoń­czoną, którą cię­gle spraw­dza stan gniazda serwera.

Pierw­sza implementacja

Spró­bujmy stwo­rzyć pierw­szy dzia­ła­jący ser­wer. Nie będzie on pozwa­lał na prze­ka­zy­wa­nie danych innym użyt­kow­ni­kom, a połą­cze­nia nie będą utrzymywane.

<?php 
set_time_limit(0);
 
class GameServer
{
	private $master;
	private $address; 
	private $port; 
	private $maxClients;
 
	public function __construct($address = '127.0.0.1', $port=14117, $maxClients = 10)
	{
		$this->address = $address;
		$this->port = $port;
		$this->maxClients = $maxClients;
 
		$this->master = socket_create(AF_INET, SOCK_STREAM, SOL_TCP); 
		socket_bind($this->master, $this->address, $this->port);
		socket_listen($this->master); 
 
		while(true)
		{
                        // akceptujemy połączenie, tworzymy gniazdo 
			$socket = socket_accept($this->master); 
 
			// odczytujemy informacje z gniazda
			$input = socket_read($socket, 1024); 
 
			// przygotowujemy dane do wysyłki
			$output = 'Wyslales do serwera: '.$input.chr(0); 
 
			// Wysyłamy dane użytkownikowi
			socket_write($socket, $output);
 
                        // zamykamy połączenie z użytkownikiem
			socket_close($socket); 
		}
	}
 
	public function __desctruct()
	{
		// zamknięcie głównego gniazda
		socket_close($this->master); 
	}
}
 
$gameServer = new GameServer();
?>

Two­rzymy obiekt $game­Se­rver. W kon­struk­to­rze możemy podać kilka para­me­trów: adres i port pod jakim ser­wer będzie nasłu­chi­wał oraz mak­sy­malną ilość użytkowników(ta zmienna nie jest uży­wana w tym przy­kła­dzie lecz przyda się później).

Kilka słów o nume­ra­cji portów

W przy­padku IP w wer­sji czwar­tej do dys­po­zy­cji mamy 2¹⁶ por­tów. Te o nume­rach poni­żej 1024 wyma­gają upraw­nień admi­ni­stra­cyj­nych. W więk­szo­ści przy­pad­ków są one już zare­zer­wo­wane dla innych usług(np. 80 dla http, 23 dla ftp, 21 dla tel­net itd.). Naj­wy­god­niej jest po pro­stu ich nie ruszać.

Do zmien­nej $this->master zapi­sy­wane jest główne gniazdo ser­wera two­rzone za pomocą socket_create(). To ono będzie odbie­rało wszyst­kie infor­ma­cje przy­cho­dzące od innych użyt­kow­ni­ków. Co ozna­czają para­me­try wewnątrz?

• Pierw­szy infor­muje jaka rodzina pro­to­ko­łów będzie uży­wana w przy­padku naszego gniazda. AF_INET okre­śla, że będą to protokoły(TCP oraz UDP) w opar­ciu o IPv4. Możemy rów­nież poin­for­mo­wać o uży­ciu IPv6 zamie­nia­jąc ten para­metr na AF_INET6.
• Drugi para­metr okre­śla rodzaj trans­mi­sji. Do wyboru mamy:
  • SOCK_STREAM — infor­ma­cje prze­sy­łane są w obu kie­run­kach jed­no­cze­śnie, bez spadku trans­feru, sekwen­cyj­nie oraz nie­za­wod­nie za pomocą stru­mieni baj­tów. Bazo­wym pro­to­ko­łem jest TCP.
  • SOCK_DGRAM — data­gra­mowy pro­to­kół bez­po­łą­cze­niowy z bra­kiem kon­troli prze­pływu i retrans­mi­sji. Bazo­wym pro­to­ko­łem jest UDP(To jest dobry wybór w przy­padku pisa­nia gry internetowej!).
  • SOCK_SEQPACKET — infor­ma­cje prze­sy­łane są w obu kie­run­kach jed­no­cze­śnie, bez spadku trans­feru, sekwen­cyj­nie. Od klienta wyma­gane jest aby odczy­ty­wane były całe pakiety przy każ­dym zapytaniu.
  • SOCK_RAW — gniazdo RAW czyli bez­po­średni do niego dostęp. Umoż­li­wia to stwo­rze­nie wła­snego pro­to­kołu komu­ni­ka­cji. Opcja raczej dla zaawan­so­wa­nych użytkowników.
  • SOCK_RDM — nie­za­wodna trans­mi­sja pakie­tów nie gwa­ran­tu­jąca porząd­ko­wa­nia pakie­tów. Ta opcja nie zadziała w wielu sys­te­mach ope­ra­cyj­nych. Raczej dla zaawan­so­wa­nych użytkowników.
• Ostatni para­metr to po pro­stu ID pro­to­kołu. W przy­padku TCP oraz UDP możemy sko­rzy­stać ze sta­łych SOL_TCP(6) oraz SOL_UDP(17). Pełną listę iden­ty­fi­ka­to­rów znaj­dziesz w /etc/protocols

W naszym przy­kła­dzie stwo­rzy­li­śmy gniazdo wyko­rzy­stu­jące pro­to­kół TCP. W kolej­nej lini infor­mu­jemy nasze gniazdo pod jakim adre­sem i jaki port ma nasłu­chi­wać. Gdy to okre­ślimy uru­cha­miamy nasłuchiwanie.

Ten pro­ces jest bar­dzo pro­sty. Stwo­rzona została pętla nie­skoń­czona, która przy każ­dym obro­cie akcep­tuje gniazdo przy­cho­dzące. następ­nie odczy­tuje z niego dane, odsyła je do użyt­kow­nika oraz zamyka połą­cze­nie. Ser­wer uru­cho­miony raz będzie dzia­łał w nieskończoność(prawie w nie­skoń­czo­ność ) więc ważne jest aby wyłą­czyć spraw­dza­nie czasu wyko­ny­wa­nia się skryptu. W tym celu w pierw­szej linijce kodu wid­nieje wywo­ła­nie funk­cji set_time_limit()

Testu­jemy serwer

Uru­chom kon­solę z dwoma zakład­kami. Aby uru­cho­mić nasz ser­wer w pierw­szej wpisz:

php server.php

W dru­giej spró­bujmy akty­wo­wał połączenie

hellson@hellson:~> telnet 127.0.0.1 14117
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Hello
Wyslales do serwera: Hello
Connection closed by foreign host.
hellson@hellson:~>

W przy­padku zamknię­cia skryptu wyko­nany zosta­nie destruk­tor zamy­ka­jący gniazdo główne.

Mam nadzieję, że ten arty­kuł uła­twił ci zro­zu­mie­nie idei gniazd. Już jutro kon­ty­nu­acja tematu. Ulep­szę kod ser­wera tak aby odbie­rał infor­ma­cje od róż­nych użyt­kow­ni­ków jed­no­cze­śnie. Połą­cze­nie będzie utrzy­my­wane aż do momentu wpi­sa­nia „exit“ przez użytkownika.