Pierwszy sposób to ustawienie przekierowania pakietów. Można do tego użyć programu socat. Najpierw musimy ustawić w aplikacji nasłuchiwanie na jakimś z „wyższych” portów, a następnie uruchomić program socat na koncie roota:

socat TCP-LISTEN:80,fork,su=nobody,reuseaddr TCP:127.0.0.1:8080 – przy takiej konfiguracji program socat przekieruje pakiety z portu 80, na port 8080.

Wadą sposobu z przekierowaniem jest to, że zużywamy w ten sposób więcej systemowych zasobów, a po drugie, nasza aplikacja nie może odczytać adresu ip osoby, która się połączyła z serwerem.

Lepszy sposób

O wiele lepszym sposobem byłoby uruchomienie aplikacji z prawami roota, wykonanie wszystkich akcji wymagających uprawnień (np. otwarcie gniazda serwera na porcie 80) i utracenie przywilejów – przejście do trybu zwykłego użytkownika. Tylko jak to zrobić w javie? Z pomocą przychodzi nam biblioteka Apache Commons Daemon. Uruchamia ona naszą aplikację jako systemowy Daemon. Z prawami roota wywołuje funkcję init() naszego programu, a następnie traci prawa roota i wywołuje funkcję start(). Można ją pobrać tu. Biblioteka składa się z dwóch częsci. Jedna – to bilbioteka napisana w javie – musimy ją dołączyć do aplikacji, a druga, to narzędzie jsvc, które możemy pobrać z powyższej strony, a w niektórych systemach zainstalować z repozytorium: apt-get install jsvc.

Na początek musimy zmodyfikować naszą aplikację. Tworzymy nową klasę, która będzie implementowała interfejs Daemon:

 1 package myapp;
 2
 3 import org.apache.commons.daemon.Daemon;
 4 import org.apache.commons.daemon.DaemonContext;
 5 import org.apache.commons.daemon.DaemonInitException;
 6
 7 /**
 8  *
 9  * @author jblew
10  */
11 public class Main implements Daemon {
12
13     public void init(DaemonContext dc) throws DaemonInitException, Exception {
14         /**
15          * Ta funkcja jest uruchamiana pierwsza, z prawami roota. Tutaj należy otworzyć sockety na portach mniejszych niż 1024, np. 80.
16          */
17     }
18
19     public void start() throws Exception {
20         /**
21          * Ta metoda jest uruchamiana druga, po init(), ale już bez praw roota. Tutaj uruchamiamy aplikację.
22          */
23     }
24
25     public void stop() throws Exception {
26         /**
27          * Tutaj zakańczamy aplikację.
28          */
29     }
30
31     public void destroy() {
32         /**
33          * A tu powinniśmy zniszczyć obiekty utworzone przez funkcję init().
34          */
35     }
36 }
37
38

Ta klasa będzie odpowiedzialna za uruchamianie naszego programu. Teraz pozostała jeszcze tylko kwestia, jak to zrobić.
Do uruchamiania tak spreparowanej aplikacji służy polecenie jsvc. Postaram się to wytłumaczyć na przykładzie:

sudo jsvc -user [nazwa użytkownika] -debug -cp MyApp.jar myapp.Main – To polecenie uruchomi opisane wyżej funkcje klasy myapp.Main, z pliku MyApp.jar. Dzięki parametrowi -debug zobaczymy wyjście apikacji i wszystkie błędy, jakie wystąpią. Koniecznie musimy dołączyć parametr -user, bo inaczej cała aplikacja będzie działała z prawami roota, a po dołączeniu tego parametru, dalsza część aplikacji przejdzie na konto użytkownika, którego podamy.

I to w zasadzie wszystko. Chciałbym jeszcze tylko pokazać, jak można restartować i wyłączać daemona, bo nie da się tego zrobić w standardowy sposób. Najłatwiej to zrobić z wewnątrz naszego programu. Zauważ, że funkcja init(DaemonContext dc) przyjmue jako parametr obiekt DaemonContext, który umożliwia pobranie kontrolera daemona (metodagetController()). Właśnie Kontroler Daemona (DaemonController) umożliwia wyłączenie aplikacji metodą shutdown() i restart – metodą reload(). Wystarczy więc zachować kontroler po uruchomieniu funkcji init() i w odpowiednim czasie wykonać funkcje wyłączające.

Rozwiązanie jest proste. Wystarczy zainstalować jdk: apt-get install openjdk-6-jdk. I gotowe.

Dlaczego to piszę? Jak we wszystkich poprzednich postach, znowu muszę wspomnieć o mudzie… Podczas pisania zauważyłem, że gdy użytkownik wyda jakąkolwiek komendę, zużycie ramu zwiększa się nawet o 50kb! Na szczęście szybko znalazłem przyczynę. Okazało się, że, jak zwykle winny jest programista, a nie kto inny. Otóż gdy użytkownik wpisywał komendę tworzona była nowa klasa Command, która tą komendę przetwarzała. I tu był błąd! Przy każdym tworzeniu tej klasy kompilator musiał zarezerwować pamięć. Szybko zorientowałem się, o co chodzi i poprawiłem kod tak, że klasa Command jest tworzona, gdy użytkownik wejdzie do gry, a potem jest wywoływana tylko jej metoda. Wspaniały profiler netbeansa pokazał wyraźnie różnicę w zużyciu pamięci.

Ale najlepsze okazało się dedykowane API dla skryptów – javax.script.

Jest bardzo proste w obsłudze. Poniżej przedstawiamprzykład i opis:


package scriptingtest;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;

public class Main {
public static void main(String[] args) throws ScriptException {
ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName("JavaScript");

Proba p = new Proba(); //zawiera tylko pole int i

System.out.println(p.i);
}
}

Klasa Próba zawiera tylko pole public int i = 0; . Uruchamiając program zobaczymy, że skrypt zmieni wartość i z 7 na 2. To wszystko. Jak widać jest to bardzo proste i może być przydatne w dużych aplikacjach, szczególnie w grach.

Należy tylko pamiętać, że jeśli chcemy zaimportować jakąś klasę z wewnątrz jara, w którym uruchamiamy program, muśimy dodać na początku Packages.nazwapakietu.

Kod

No to teraz opowiem troche o kodzie. Gdyby ktoś chciał go obejrzeć, może to uczynić przez Subversion. Bieżąca wersja projektu znajduje się w folderze v2:
svn co svn://91.210.130.79/marines-mud marines-mud

Na samym początku postanowiliśmy, że podzielimy muda na program serwera i skrypt obsługujący użytkownika (oddzielny dla każdego usera). Po uruchomieniu serwer oczekiwał na nadchodzące połączenia. Gdy już jakieś zaakceptował, przenosił je do oddzielnego wątku i uruchamiłałał skrypt do obsługi użytkownika. Wątek odbierał dane do użytkownika, aby wysyłać je do skryptu i vice versa.

Pierwsza wersja muda była oparta na architekturze JAVA+PHP+MYSQL. OMG!? No właśnie… nie najszczęśliwsze połączenie. Problemem tej wersji była właściwie tylko java. Java jest fajna do programowania, bo prawie wszystko robi za programistę i zawiera mnóstwo bibliotek, które znacznie ułatwiają pracę. Zaraz, zaraz! Mnóstwo bibliotek = mnóstwo zużywanej pamięci! Największym problemem „javovej” wersji było horrendalne zużycie ramu. Na początek skrypt zabierał ok 70mb ramu, a potem zabierał kolejne 16mb na każdego użytkownika. Koszmar!

Zaraz potem próbowaliśmy szczęścia z pythonem zamiast javy. Jednak z pythonem był taki problem, że nijak nie mogliśmy zmusić biblioteki socketserver aby umożliwiła nam ponowne używanie portu.

Wreszcie postanowiliśmy w roli serwera użyć programu napisanego w c++. Nadal jednak mieliśmy problemy, tym bardzoej, że żaden z nas nie był doświadczonym programistą tego zacnego języka.

Ostatecznie zdecydowaliśmy się scalić skrypt z serwerem i tak powstała najnowsza wersja muda, w całości napisana w php. Sprawuje się bardzo dobrze, nie zużywa nadmiernie pamięci i ogólnie jestem z niej bardzo zadowolony. Dlatego opiszę ją dokładniej.

Wielowątkowość w php

Wiele lat myślałem że to niemożliwe. Cały czas zdawało mi się, że w php nie ma wielowątkowości. Kilka dni temu dowiedziałem się, że jednak jest! Ale tylko w systemach uniksowych. Jako, że jestem już szczęśliwym posiadaczem ubuntu, nie stanowi to żadnego problemu. Znalazłem też w sieci fajną klasę, która umożliwia czytelniejszą obsługę wątków w obiektowym stylu. Dzięki tej klasie obsługa wątków jest dziecinnie prosta. Autor zamieścił przykłady jej zastosowań.

Pierwsze uruchomienie

Jeśli ktoś chce uruchomić u siebie serwer, albo stworzyć innego muda na podstawie kodu, nie ma problemu. Proszę tylko o pozostawienie informacji o autorach (można dopisać swoje autorstwo).

Aby uruchomić muda należy najpierw utworzyć bazę danych phpmud, a następnie zaimportować tabele z pliku ./v2/other/sql/phpmud.sql. Kolejną sprawą jest ustawienie loginu i hasła do bazy danych, w plikach: ./v2/includes/mysql.php, ./v2/includes/globalMysql.php i ./v2/lib/class.mudUser.php. We wszystkich powinny znajdować się te same dane. Potem otwieramy trzy konsole, lub trzy okna screena, jak kto woli i w jednym uruchamiamy polecenie php tickers.php, w drugim php mobs.php, a w trzecim php phpMudServer.php. Jeśli wszystko będzie działało, w ostatnim oknie powinniśmy zobaczyć taki ekran:

   +----------------------------------+
   |   MudServer For PHP Muds v0.51   |
   +----------------------------------+
   |   Written by:                    |
   |        +JBLEW (www.jblew.pl)     |
   |        +PROGTRYK                 |
   +----------------------------------+

Setting server online...
Starting console reader...
Wpisz quit aby zakończyć program.
Starting SVNUpdater...
Listening on port 9000...
[0s od uruchomienia] Mysqli działa prawidłowo!
W wersji 418.

Jak to wszystko działa?

Skoro już uruchomiłeś muda, to opiszę teraz, jak on działa.
Pierwszy uruchomiony program – tickers.php jest mudowym odpowiednikiem crona. Tam wykonują się wszystkie periodyczne operacje, jak np. informowanie użytkowników o dniu/nocy, czy resetowanie obiektów w roomach.

Drugi program – mobs.php docelowo będzie obsługiwał moby, narazie jednak nie robi nic. Możesz go wyłączyć.

Najważniejszy jest trzeci skrypt – phpMudServer.php – to on obsługuje całego muda i co 30 sekund aktualizuje SVN.  Otwórz teraz w jakimś edytorze ten plik i zjedź aż do miejsca, gdzie znajduje się polecenie set_time_limit(0); Z pewnością wiesz, po co je tam umieściłem. Prawdziwa zabawa zaczyna się dopiero od linijki set_server_online(„1″);. Funkcja ta wpisuje „1″ do pliku data/online.dat, co jest dla skryptów znakiem, że serwer pracuje. Dalej uruchamiamy wątek consoleReader, który odczytuje kolejne linie z stdin i oczekuje aż wpiszemy quit. Wtedy wykona polecenie set_server_online(„0″);, dzięki czemu reszta wątków będzie wiedziała, że czas się wyłączyć. Dalej tworzymy nasłuchujące gniazdo, a potem w pętli oczekujemy połączenia, przy okazji co sekundę wysyłając bezsensowne polecenie do mysql-a, aby utrzymać połączenie. Gdy nowy użytkownik się połączy, serwer uruchamia wątek userThread. Przenieśmy się zatem do tej funkcji. Tworzy ona klasę MudUser i przekazuje jej gniazdo, oraz wątek. Następnie wywołuje metodę run, i od teraz użytkonik jest przenoszony do skryptu ./v2/lib/class.mudUser.php.

No. Na dzisiaj to wystarczy, jutro, albo pojutrze opiszę, co się dalej dzieje w tej klasie. Dziękuję za uwagę!

Z każdego znacznika <item> (w kanale rss) potrzebujemy 3 znaczników: <title>, <pubDate> i <link>.

Niektórzy pewnie chcieliby pewnie wyciągnąć te dane używając wyrażeń regularnych. Do dzisiaj należałem do tych ludzi. Używanie bibliotek parsujących xml wydawało mi się skomplikowane i nieprzyjemne. Jednak w istocie tak nie jest. PHP posiada łatwą w użyciu bibliotekę DOMDocument. W naszym wypadku kod jest naprawdę krótki:

$objDOM = new DOMDocument();
    //pobieramy kanal rss i tworzymy liste zawierajaca elementy ITEM
$objDOM->load("http://adres.kanalu.rss/z/twittera"); 
$items = $objDOM->getElementsByTagName("item");

Jak widzicie korzystanie z tej biblioteki to czysta przyjemność. Wszystko można zrobić szybko i sprawnie. Kod łatwo jest zmodyfikować do swoich potrzeb.

Oczywiście to „zabezpieczenie” będzie użyteczne dopiero gdy hakerowi uda się włamać na stronę, jednak nie możemy wykluczać takiego przypadku, a każda forma obrony naszej witryny jest warta zastosowania!