Denevérek a barlangban

Szerző:

É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):

Denevérek a barlangban - Osztálydiagram

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:

Denevérek a barlangban - animáció

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.

Ajánljuk a Java EE szoftverfejlesztő tanfolyam kategóriából

“Denevérek a barlangban” bejegyzéshez 6 hozzászólás

  1. 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…

    Válasz

  2. 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?

    Válasz

    • 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.

      Válasz

Szólj hozzá!