Évekkel ezelőtt hálózatos Java EE esettanulmányt akartunk készíteni Lengyel Borisz kollégával. Ötleteltünk: milyen technológiával és hogyan kommunikáljon egymással a szerver és a kliens(ek). A távoli metódushívás (Remote Method Invocation) mellett döntöttünk és elkészült a denevérek a barlangban projekt, amely evolúciós projektként azóta több változatot is megélt. A felhasználói felület (barlang) betölt néhány képet (denevér kliensek), amelyek a szerver segítségével mozognak.
Ismertetjük a tervezés folyamatát, a kliens és szerver funkcióit részletesen, végül ötleteket adunk a továbbfejlesztésre.
A főbb feladatokat így határoztuk meg:
- az RMI kommunikációs módszer megismertetése,
- az RMI szolgáltatás reprezentálása látványos grafikus/swinges klienssel,
- alternatíva nyújtása a TCP protokoll közvetlenül csatlakozó socket-jére.
Elkészítettük az alábbi osztálydiagramot (persze ez nem az első változat):
A szerver és kliens funkcióit megvalósító osztályok/interfészek feladatait így határoztuk meg:
BarlangDenevérInterfész interfész:
- véletlen 5 és 10 közötti a denevérek száma,
- méretek a GUI-hoz.
Denevér osztály:
- megvalósítja az RMI kliens funkciót,
- JLabel leszármazott, külső képfájlt tölt be ( bat.jpg),
- egyedi azonosítója van,
- eldönti mozgásának irányát (4) és léptékét (3), mintha ultrahangot adna,
- a szerver megadja neki, hogy az új helyre elmozdulhat-e,
- saját magát képes mozgatni.
Pozíció interfész:
- öröklődik a java.rmi.Remote interfészből,
- két távolról hívható metódus fejét tartalmazza.
BarlangSzerver osztály:
- megvalósítja az RMI szerver funkciót,
- implementálja a Pozíció interfészt,
- JFrame leszármazott,
- figyel arra, hogy a denevérek ne mozogjanak ki a barlangból.
BarlangFelület osztály:
- JFrame leszármazott,
- GUI az RMI kliensek megjelenítéséhez.
BarlangSzerverTérkép osztály:
- JPanel leszármazott,
- GUI a szerveren a kliensek mozgásának követésére.
Ha futtatjuk az elkészült szerver és kliens programot, akkor ezt láthatjuk:
A fejlesztés és tesztelés közben sok-sok továbbfejlesztési ötletet/javaslatot fogalmaztunk meg:
- háttérkép a barlangról,
- a háttérkép megvalósíthat labirintust, koordináta-rendszert,
- átlátszó illetve egyedi képfájlok a denevéreknek,
- a denevérek mozgásának tetszőleges iránya (360°),
- a denevérek mozgásának egyedi léptéke,
- a denevérek figyeljenek egymásra (ne ütközzenek össze),
- a denevérek figyeljenek a környezetükre (ne ütközzenek bele sziklákba, cseppkövekbe),
- a szerver követheti a denevérek útvonalát,
- a szerver archiválhat, szerializálhat, készíthet statisztikát.
A bejegyzéshez tartozó – több lépésben továbbfejlesztett – forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.
A feladat a Java EE szoftverfejlesztő tanfolyam 21-24. óra: RMI alapú kommunikáció alkalmához kapcsolódik.
Megosztanám néhány ötletemet a továbbfejlesztéshez:
– beépülhetne valamilyen fertőzési modell, pl. van kezdetben egy beteg (piros) denevér és az megfertőzi a vele érintkezőket, vagy a hozzá közel repülőket és a betegség tart egy ideig és utána meggyógyul mondjuk 80% vagy elpusztul 20% arányban,
– lejárhatna a denevérek életciklusa, pl. adott db kérdés után már nem kapnának választ a szervertől (romlik a hallásuk) és leesnének, elpusztulnának,
– lehetne random eltérő, hogy melyik denevér milyen gyakran kérdez (aktívabb, lustább),
– lehetne a denevéreknek neme és szaporodhatnának is: ehhez tartozhatnának különböző időintervallumok/állapotok, pl. fiatal, ivarérett, randevú, adott % arányában vemhes lesz, születik, öregszik…
Örülök, hogy ilyen jól átgondoltad ezeket Kristóf. Ha lesznek megoldásaid, kérlek töltsd fel az ILIAS-os csoport fórumába és vitassátok meg.
Olvastam a JavaDocban, hogy a sun.rmi.transport.tcp.maxConnectionThreads int típusú. Ez 2 milliárd fölötti klienst jelent. Péter, mit jelent ez a gyakorlatban?
Linkeltem a hivatkozott JavaDoc-ot: https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/sunrmiproperties.html
Jól látod Kristóf, ez a property elméleti felső korlát. A gyakorlatban az RMI szerver áteresztőképessége – hogy mennyi klienst képes kiszolgálni biztonságosan kvázi egyszerre és adott válaszidőn belül – komplex kérdés. Írok néhány példát:
– Milyen egyszerű a kérdés/válasz jellegű kommunikáció? Mit kell a szervernek tennie, hogy válaszolni tudjon? Ebben a programban téglalapok tartalmazottságát kell eldöntenie, ami nagyon egyszerű részfeladat. RMI-vel megvalósítható hálózati login/regisztráció is, amihez űrlapo(ko)n megadott – jó esetben kódolva érkezett szöveges név és jelszó párt visszafejtve – adatok ellenőrzéséhez adatbázishoz kell fordulni. Ez jóval tovább tart. Hasonlóan hosszabb az időigénye egy nagyon AB tranzakciónak is, ami érinthet sok rekordot, több táblát, ellenőrzéseket is tartalmazhat.
– Számít, hogy mennyi adatot küldünk és azzal mi történik. Például videófájlok feltöltéséhez is használhatjuk az RMI-t, darabolt részeket küldve. Ekkor is vannak tesztelendő gyenge láncszemek a kommunikációban.
– Építhetünk több lépésből álló kommunikációt is, az adatok biztonsága érdekében. Például: küldök, megkapod, mented, visszajelzel-szerű protokoll esetében.
– Nagyobb léptékekben gondolkodva nyilván a szerver hardvere is számíthat: memória mérete, hagyományos merevlemez vagy SSD, de általában gyengébb láncszem lehet a kis(ebb) sávszélesség.
A lényeg: az elosztott alkalmazás funkciói és kialakított kommunikációja nagyban befolyásolja egy kialakított hálózati kapcsolat teherbírását, kapacitását, biztonságát, áteresztőképességét. Több 100 klienst bármelyik RMI típusú kommunikáció gond nélkül elbír.
A denevérek esetében teszteltük a szervert 1000 klienssel és grafika nélkül gond nélkül ment. Listába – memóriába – logoltunk és a végén fájlba írva ellenőriztük, mi történt adott idő alatt. Itt a gyenge láncszem a grafika.
Köszi Péter. Jól sejtettem, hogy ez már nehezebb történet. Mindenképpen tervezni és optimalizálni kell.