Dejan332

Na wstępie zaznaczę, że NIE jest to poradnik o używaniu MySQL w AMX, ale o DOBRYM jego używaniu. Kto czytał mój poradnik o dobrych nawykach tworzenia menu, ten wie o co chodzi

Powstaje coraz więcej pluginów z użyciem MySQL, ale czy są to dobrze napisane pluginy? Na pewno nie wszystkie. O ile w większości przypadków do samych realizacji funkcji pluginu na serwerze nie można się przyczepić, o tyle komunikacja z bazą danych pozostawia wiele do życzenia. Pół biedy, gdy mamy serwer SQL na tej samej maszynie, albo na maszynie w jednej sieci... Albo gdy używamy SQLite. Ale większość serwerów posiada bazę SQL w zupełnie innej lokalizacji. Często serwer gry jest w Polsce, a SQL we Francji, Niemczech... Czym to owocuje?

Popatrzmy.. Sami wiemy, że serwery zagraniczne do grania mixów się nie nadają raczej, zbyt wysoki ping. Podobny ping do takiego serwera ma dowolny serwer gry postawiony w Polsce, potrafi się on wahać od 100 do 500 milisekund, czyli aż do pół sekundy! To już całkiem sporo jak na przetworzenie zapytania... O ile samo przetworzenie nie zajmuje dużo, przy dobrze skonfigurowanym serwerze nie jest to nawet 1 milisekunda, o tyle wysłanie go i odebranie wyniku już trochę trwa...

Popatrzmy na taki prosty przykład (przyjmijmy średni ping na 150 ms do zagranicznych serwerów), AmxBans, dowolna ich wersja... Gracz wchodzi na serwer, wykonywane są po kolei następujące zapytania:

• Sprawdzenie, czy gracz nie posiada bana.
• Jeśli ban został znaleziony:
  
  • Jest aktywny: zwiększenie ilości kicków w danych o banie (dotyczy GmBans), dalsze zapytania niewykonywane
  • Jeśli nie jest aktywny: przesunięcie go do archiwum
• Sprawdzenie, czy gracz nie został oflagowany
• Sprawdzenie, czy gracz nie posiadał wcześniej żadnych banów
• Jeśli używamy bazy sql zamiast users.ini - sprawdzenie, czy gracz nie jest adminem

W pesymistycznym przypadku - 5 zapytań SQL, w optymistycznym (aktywny ban) 2. W normalnym (brak aktywnych banów): 4. Dosyć sporo. A wszystkie, prócz ostatniego można ograniczyć do TYLKO jednego zapytania. Jakby się postarać to i ostatnie można podłączyć do tego zapytania, ale nie ma to sensu bo nie dalibyśmy wtedy użytkownikowi wyboru czy chce używać users.ini czy bazy danych do przechowywania adminów.

Założyliśmy, że średni ping wynosi 150ms, czyli w uproszczeniu daje nam to 150ms na jedno zapytanie (w rzeczywistości trwa to jednak dłużej), więc 750ms przy pesymistycznej wersji będzie trwało ustalenie z kim mamy do czynienia, prawie sekunda! a graczy możemy mieć nawet 32, przy zmianie mapy te wszystkie zapytania się wykonują! W tym artykule pomogę Wam takich koszmarków unikać...


Projekt bazy danych.
Pierwszą rzeczą, którą musimy uczynić przy tworzeniu pluginu wykorzystującego bazę danych, jest odpowiedni projekt samej bazy danych. Najpierw musimy wiedzieć co zapisujemy. Czy chcemy stworzyć exp moda? Może jakieś statystyki dla graczy zapisywać? A może wszystkie serwery sieci zebrać w jednej bazie danych na potrzeby pluginu takiego, jak xRedirect?

Gdy to już wiemy, następna rzecz to to, co chcemy na dany temat w bazie umieścić. Przyjmijmy dla przykładu, że tworzymy plugin zliczający czas gry na naszym serwerze każdego gracza, który nań wejdzie. Dla uproszczenia przyjmijmy również, że serwer jest Steam Only (nie mam zamiaru igrać z prawem tutaj ), dzięki czemu każdego gracza po SteamID można rozpoznać.

Więc co musimy w bazie zapisać? Na pewno jego SteamID oraz czas gry na serwerze. Czyli mamy już 2 kolumny w bazie danych, dopiszemy jeszcze trzecią, id. Czym będzie ID? Identyfikatorem ułatwiającym nam operację na bazie danych Szybciej w bazie jest wyszukiwać po liczbach, niż po napisach. Więc będziemy mieli 3 kolumny:

• `id` INT(11) NOT NULL auto_increment
• `sid` VARCHAR(24) NOT NULL
• `time` INT(11) NOT NULL

Przy ID dodajemy auto_increment. Dzięki temu każdy id będzie większy o 1 od poprzedniego dodanego do bazy. Dalej mamy string `sid` długości 24 znaków. 20 znaków zajmuje najdłuższy spotkany przeze mnie Steam ID. Dajmy dodatkowe znaki, jakby w przyszłości się rozrosły. Time jest typu INT, czyli liczbą. Wszak czas możemy zapisać w formie ilości sekund przegranej na serwerze. Tak najprościej go jest przechować i przetwarzać (dodawać, odejmować...)

Mamy 3 kolumny, ale to jeszcze nie wszystko. Dodamy klucze! Czym są klucze? Dają nam one unikalność danych w kolumnie, szybkość wyszukiwania i definiują również jaka kolumna jest indeksem w tabeli. Dodamy 2 klucze, ponieważ ID ma być indeksem tabeli (PRIMARY KEY), a sid musi być koniecznie unikalne. Możemy to pominąć, ale zobaczycie jak to ułatwi później budowę zapytania Więc indeksy:

• PRIMARY KEY (`id`)
• UNIQUE KEY `sid` (`sid`)

No dobrze, ale co gdy mamy sieć serwerów, a czas chcemy dla każdego serwera zapisywać osobno? Trzeba każdemu serwerowi nadać jakieś id (najlepiej w formie liczby i najlepiej też zapisać je po prostu w osobnej tabeli w bazie danych, w której będą dane odnośnie serwerów). Wtedy dodamy tylko kolumnę oznaczającą nasz serwer
`server` INT(11) NOT NULL
oraz zmodyfikujemy indeks `sid` na taki:
UNIQUE KEY `server_sid` (`server`, `sid`)
Jak ten indeks zadziała? Ano nie pozwoli on, aby w bazie znajdował się wpis z takim samym Steam ID oraz takim samym numerem serwera. Czyli gdy mamy 2 takie same Steam ID, ale inne serwery to wpisy te mogą istnieć, tak samo gdy 2 inne SteamID, a 2 takie same serwery.

Cała struktura tabeli, w języku SQL będzie wyglądała tak:

CREATE TABLE IF NOT EXISTS `godziny` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `server` int(11) NOT NULL,
  `sid` varchar(24) NOT NULL,
  `time` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `server_sid` (`server`,`sid`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

Wstawianie i aktualizacja danych
Teraz przejdziemy do tego, co na serwerze. Pomyślmy co musimy zrobić w naszym przykładzie od strony serwera? Otóż wstawić nowy rekord w bazie z danymi gracza, lub go aktualizować jeśli już istnieje. Jak można to zrobić? Sprawdzić czy rekord istnieje, jeśli tak to zaktualizować, jeśli nie to wstawić nowy... czyli 2 zapytania dla każdego gracza by się musiały wykonać, ale czy muszą? Pomyślmy... A jakby zapytanie samo zdecydowało czy wstawić, czy zaktualizować? A da się tak? A da

Ale pozostaje jeszcze problem przy aktualizacji. Musimy odpowiednio zwiększyć starą wartość czasu, a nie wstawiać nową bezmyślnie, podmieniając starą... Możemy pobrać po prostu starą wartość, dodać i wpisać nową... NIE, tak nie zrobimy! Bo to też oznacza 2 zapytania (co prawda niekoniecznie w ciągu, jedno po drugim, ale dwa!).

Więc mamy do wyboru: Odpowiedni warunek używając SELECT, UPDATE oraz INSERT INTO w jednym zapytaniu... Długie ono niestety wyjdzie i ciężko jest je skonstruować. Drugim rozwiązaniem jest REPLACE INTO. Działa ono tak, że stary rekord usuwa, gdy taki istnieje, a następnie tworzy nowy. Tutaj niestety nie możemy się do starej wartości odwołać. Mamy jeszcze jakieś rozwiązania?

Tak, mamy. Dzięki odpowiednio skonstruowanym kluczom możemy po prostu użyć INSERT INTO. No nie tak po prostu, dopiszemy na końcu ON DUPLICATE KEY UPDATE, co spowoduje, że gdy zapytanie INSERT się nie powiedzie, z powodu istniejących już wartości w polach unikalnych, zostanie wykonane UPDATE. Niestety to UPDATE, jest z pewnych powodów trochę uproszczone w porównaniu do klasycznego.

Najpierw skonstruujmy samego INSERTa:

INSERT INTO `czasy` (`server`, `sid`, `time`)
VALUES (%d, '%s', %d)

Jak widać proste zapytanie Dla czytelności podzieliłem na 2 linie. Teraz nasze UPDATE:

INSERT INTO `czasy` (`server`, `sid`, `time`)
VALUES (%d, '%s', %d)
ON DUPLICATE KEY UPDATE
`time` = `time`+%d

Oto i nasz update. Tak, tak się da, serwer SQL wtedy ładnie zwiększy `time` o wartość przez nas podaną. Jednakże napiszemy to troszkę inaczej.

INSERT INTO `czasy` (`server`, `sid`, `time`)
VALUES (%d, '%s', %d)
ON DUPLICATE KEY UPDATE
`time` = `time`+VALUES(`time`)

Ta funkcja spowoduje pobranie wartości, którą podaliśmy przy INSERT. Niby wychodzi troszkę większa ilość znaków, ale za chwilę zobaczycie dlaczego tak.


Odpowiednie umiejscowienie w kodzie pluginu
Teraz rzecz na której ludzie najczęściej się potykają. Kiedy wysyłać dane na serwer? Najprościej by było gdy gracz się rozłączy i pod koniec mapy, co sprowadza się do jednego: client_disconnect. A to jest błąd, duży błąd... Gdyż oznacza to przy pełnym 32 slotowym serwerze wysłanie 32 zapytań pod koniec mapy. Może i niedużo, ale jednak coś. Pytania nie są wysyłane na raz, ale po kolei. Nie mam tu na myśli, że zakończy się jedno, a wyśle drugie. Wysyłane są po kolei, a odbierane w kolejności wysłania. Więc jeśli np 15 zapytanie utknie, to reszta musi czekać. Jeśli odpowiedź z 7 utknie to znów reszta na odbiór musi czekać. Przydałoby się to upchnąć w plugin_end w jednym zbiorczym, np tak:

INSERT INTO `czasy` (`server`, `sid`, `time`) VALUES
(%d, '%s', %d),
(%d, '%s', %d),
(%d, '%s', %d),
(%d, '%s', %d)
ON DUPLICATE KEY UPDATE
`time` = `time`+VALUES(`time`)

Wszak można wrzucić od razu wszystkich graczy w ten sposób (tu jest tylko 4). Ale hmm.. Najpierw się wykonują wszystkie client_disconnect, a dopiero później plugin_end. Więc trzeba jakoś to "przechwycić". Dodatkowym problemem jest to, że będzie potrzebna bardzo duża tablica, aby to wszystko zmieścić. Najpierw poradźmy sobie z 2 problemem, co nam częściowo rozwiąże 1. Zauważasz pewnie tutaj dlaczego wcześniej polecilem użyć tego "magicznego" VALUES. Otóż gdy dodajemy kilka rekordów to nie mamy już możliwości wpisania tam konkretnej wartości, a ta funkcja zadba o to, aby dla każdego wpisu była użyta wartość podana przy próbie jego zainsertowania

Otóż AMX ma to do siebie (jak duża część języków programowania), że lepiej przyjmuje duże tablice, gdy są one tablicami globalnymi, niż lokalnymi. Czyli zdefiniujmy sobie query na początku pliku sma, a nie w samej funkcji tej tablicy używającej. Wielkość query sobie trzeba policzyć. Tutaj mamy na pierwszą linię 53 znaki (wraz z enterem). Na lnii z danymi graczy mamy wstawione zmienne. trzeba policzyć jaką długość każda z nich zajmie. Znaczy liczyć nie trzeba, mamy to w bazie danych: 11, 24 i 11. W sumie jest to 46. do tego 2 przecinki, 2 nawiasy, 2 spacje (dla optymalizacji można je usunąć), 2 apostrofy, przecinek na końcu i enter. 10 znaków, czyli łącznie z tymi wstawionymi ze zmiennych mamy 56. Przemnóżmy to razy 32, wychodzi 1792. Teraz 2 ostatnie linie, mają one odopwiednio 24 i 31 znaków (łącznie z enterem i nullem na ich końcach). Sumujemy i wychodzi: 1900 (o, jaka równa liczba ). Taką właśnie tablicę musimy sobie zadeklarować. To jest oczywiście przypadek pesymistyczny, więc pewnie do końca jej nigdy nie zapełnimy

Teraz problem numer 1. Jak go rozwiązać? W bardzo prosty sposób, w client_disconnect zamiast wykonywać zapytania, będziemy dopisywać do głównego naszego zapytania odpowiednie linie dla każdego "wychodzącego" gracza i wyślemy to zapytanie w plugin_end. Dodatkowo co jakiś czas (proponuję 60 sekund) będzie wykonywany task, który sprawdzi, czy jakiś gracz nie rozłączył się w trakcie trwania mapy i jeśli się rozłaczył (i dopisał do głównego zapytania) to to zapytanie wyślemy Pamiętać trzeba o kilku rzeczach: zanim zaczniemy zbierać do zapytania wartości, należy dodać początek, czyli pierwszą linię. Druga rzecz, tuż przed wysłaniem zapytania musimy skasować przecinek z ostatnio wpisanej pozycji (nie przewidzimy przecież wcześniej, że więcej już pozycji nie będzie, a jeśli precinek zostawimy to zapytanie się nie wykona, gdyż będzie błędne!) i dopisanie końcówki (ON DUPLICATE....). Początek najlepiej wpisać przy plugin_init oraz po każdym wysłaniu zapytania (oczywiście nadpisać nim cały napis, a nie dopisywać). Końcówkę tuż przy wysyłaniu Dodatkowo jeszcze musimy zadbać o to, aby nie wysyłać zapytania bez wstawionego żadnego wiersza. W tym celu najlepiej utworzyć sobie licznik, inkrementować go przy każdym dodaniu do zapytania wiersza, sprawdzić go przed wysłaniem zapytania, czy nie wynosi zero, a po wysłaniu wyzerować.

Dodatkowo możemy w tasku przejechać się pętlą po wszystkich graczach na serwerze i też wysłać ich dane, dzięki czemu przy crashu nie stracą oni dorobku z całej mapy, ale tylko najwyżej z ostatniej minuty (jeśli co minutę task się wykonuje oczywiście).

Jest jeszcze jedna rzecz. Twórcy AMX, a ściślej biblioteki sqlx przestrzegają przed używaniem ThreadedQuery w plugin_end. Dlatego polecam użyć tutaj tzw trybu liniowego (synchronicznego). Nie spowoduje to "widocznego" laga na serwerze, gdyż gracze w tym momencie będą czekać na zmianę mapy, a czas trwania tej zmiany tak samo się przez to wydłuży, jak przy ThreadedQuery (serwer przed zmianą mapy czeka, aż wszystkie zapytania ThreadedQuery zostaną zakończone).

Druga część poradnika w #12 poście w tym temacie.

[S]ystem [R]ezerwacji [N]icków
Autor: Pavulon
Wersja: 1.1 beta

Opis
Rezerwacje nicków znajdują się w bazie MYSQL dzięki czemu kilka serwerów może mieć te same rezerwacje bez dodatkowego ustawiania.

Admin przez www ma możliwość akceptowania rezerwacji (tj. nick po amx_resnick nie jest od razu zarezerwowany żeby uniknąć nieporozumień), usuwania próśb o rezerwacje, usuwania rezerwacji lub dodawania nowych oraz edytowania aktualnych.

Rezerwacja ta nie koliduje z adminami i rezerwacjami slotów gdyż bazuje na innych danych i haśle zapisanym w

setinfo _res twoje_haslo

a nie standardowo _pw.

Jest to dopiero wczesna wersja BETA, ale już powinna spełniać wszystkie wymogi. Z czasem czekają ją poprawki oraz dodatkowe funkcjonalności.


Instalacja
Zawartość folderu hlds kopiujemy/przenosimy do katalogu cstrike w naszym serwerze CS.
Zawartość folderu www kopiujemy/przenosimy do katalogu głównego(dowolnego) na naszym serwerze WWW.

Zawartość pliku srn.sql można wkleić do phpMyAdmin'a, lecz nie jest to obowiązkowe gdyż tak plugin jak i skrypt .php powinny stworzyć odpowiednie tabele.

Wymagane

serwer WWW (nie jest wymagany do końca bo i bez niego główne funkcje będą zachowane)
serwer MYSQL
odblokowany moduł mysql

Dalsza instalacja i Konfiguracja
HLDS - Cvary:

srn_sql_host "localhost" //adres Bazy Danych
srn_sql_user "user" //uzytkownik BD
srn_sql_pass "password" //haslo uzytkownika BD
srn_sql_db "database" //nazwa BD
srn_res_time "2592000" //czas rezerwacji 2592000s = 30*24*60*60 = 30 dni
srn_spam_delay "60" //czas po jakim jest info o rezerwacji 60 s
srn_maxres "1" //maksymalna liczba zarezerwowanych nickow na osobe

Jeżeli chcemy wyłączyć rezerwacje z poziomu CS'a ustawiamy srn_maxres "0"

WWW:
Po wrzuceniu wszystkich plików na serwer i przejściu do katalogu SRN (przykladowy_host.pl/SRN ) powinniśmy zostać automatycznie przekierowani na stronę SRN/setup.php która przeprowadzi nas przez konfigurację serwera mysql, tworzenie tabel i dodanie admina.

Jeżeli instalacje przejdzie pomyślnie to powinien zostać stworzony plik config.php o treści podobnej do tego:

<?php
$db_host = "ip.serwera";
$db_name = "nazwa_bazydanych";
$db_username = "uzytkownik_bazydanych";
$db_passwd = "haslo_bazydanych";
$maxres = "1";
$regactive = "1";
$captcha = "1";
$publickey = "klucz_publiczny_recaptcha";
$privatekey = "klucz_prywatny_recaptcha";
$mail = "2";
$smtphost = "adres.serwera.smtp";
$smtpport = "portserwerasmtp";
$smtpuser = "[email protected]";
$smtppass = "haslo_smtp";
?>

Jeżeli po instalacji chcemy zmienić maksymalną ilość rezerwacji na osobę to zmieniamy wartość

$maxres =  "1";

natomiast jeżeli chcemy wyłączyć rezerwacje z poziomu WWW (admini nadal będą mogli je dodawać) to ustawiamy:

$maxres =  "0";

Jeżeli chcemy wyłączyć możliwość rejestracji nowych kont to ustawiamy:

$regactive =  "0";

Admini:
Innych adminów jak i użytkowników można dodawać z panelu lub po zarejestrowaniu się użytkownika możemy zmienić jego poziom.
Dostępne poziomy to:

HEAD ADMIN => może dodawać/edytować/usuwać użytkowników i przeglądać historie
ADMIN => może dodawać/edytować/usuwać rezerwacje użytkowników
USER => może dodawać/usuwać prośby i usuwać rezerwacje

Autoryzacja:
Istnieje możliwość zmiany powiązania rezerwacji z danym graczem.
Żeby zmienić zapis należy w kodzie zmienić linijkę:

//0 - automatycznie, 1 - steamid, 2 - ip
    #define auth 0

0: standardowo zapisuje na SteamID, ale jeżeli SteamID to STEAM_ID_LAN, STEAM_ID_PENDING itd to zapisuje na IP
1: zawsze zapisuje na SteamID
2: zawsze zapisuje na IP

Po tej zmianie kod należy ponownie skompilować.

WAŻNE !!
Jeżeli posiadamy serwer NS+S (Dproto) to koniecznie musimy edytować plik dproto.cfg i do pola ValidInfoFields_Engine dodać \_res czyli przykładowo musimy otrzymać:

ValidInfoFields_Engine = \name\bottomcolor\topcolor\model\cl_lc\cl_lw\cl_updaterate\cl_dlmax\rate\_pw\*hltv\password\_res

(Tylko w starszych wersjach dproto o ile w dproto.cfg znajduje się wpis ValidInfoFields_Engine)

Komendy:
Aby wejść w menu wystarczy wpisać na chacie "rezerwacja"

say rezerwacja

Gdzie mamy możliwość I.1. Dodania, I.2. Edytowania, I.3. Usuwania, I.4. Listingowania rezerwacji, I.5. wyświetlenia informacji o SRN, I.6. adminowania
Edytować możemy I.2.a login i/lub I.2.b hasło
W menu adminowania możemy II.1. Przeładować, II.2. Usuwać rezerwacje, II.3. Zarządzać prośbami
Prośby możemy II.3.a Akceptować i II.3.b Odrzucać

Wszystko z menu.


Podczas dodawania mamy wyświetlony nick i hasło, więc w razie potrzeby możemy poprawić dane.

Podczas edytowania wyświetlony zostaje nick oraz gwiazdki zamiast hasła. W przypadku gdy zmieniliśmy hasło to do czasu akceptacji będzie ono wyświetlane.


Po dodaniu rezerwacji lub zmianie hasła do konsoli wysyłana jest automatycznie komenda setinfo z odpowiednimi danymi, lecz jeżeli gracz posiada config tylko do odczytu to musi również zapisać ją do pliku ręcznie.

Nie ma możliwości przypomnienia hasła. Wszystkie są kodowane algorytmem md5.

Póki co dostępny jest tylko język polski gdyż ta aktualizacja sprawiła że słownik rozrósł się i tłumaczenie zeszło na dalszy plan.
Wszystko co jest wyświetlane od menu przez chat do konsoli jest edytowalne w słowniku, więc każdy wybierze coś dla siebie.






Obsługa WWW:
Obsługa powinna być intuicyjna. Zaczynamy od wejścia do katalogu głównego SRN(http:// przykladowy_host.pl/SRN ) lub pliku SRN/srn.php(http:// przykladowy_host.pl/SRN/srn.php).
Tam logujemy się używając loginu i hasła podanego przy instalacji lub rejestracji.

Po poprawnym zalogowaniu się mamy dostęp do wszystkich właściwych dla naszego poziomu funkcji.


Przy każdej opcji wyświetlana jest ilość rekordów (np. rezerwacji oczekujących czy użytkowników).

Jeżeli nick rezerwuje zwykły użytkownik to musi być on zaakceptowany przez admina, natomiast jeżeli admin rezerwuje to jest on automatycznie akceptowany.


W wersji 1.1 pojawiło się wsparcie reCAPTCHA i maili.
reCAPTCHA jest wykorzystyna do operacji na użytkownikach a konkretniej do rejestracji i odzyskiwania hasła, zapewnia ochronę przed robotami.

1. Korzystamy z wewnętrznego serwera dostępnego w naszym hostingu.
2. Korzystamy z zewnętrznego serwera SMTP (np. gmail)
Jeżeli zostanie włączona jedna z opcji maila to podczas zakładania konta na adres email zostanie wysłane losowe hasło,

oraz istnieje możliwość odzyskania zapomnianego hasła(zmiany na nowe).


p.s.
Kolejnych aktualizacji nie przewiduje.

http://amxx.pl/topic...-amx-ssban-v26/