Fejlesszünk elosztott, hálózatos, datagram alapú üzenetküldéssel megvalósított Java alkalmazást!
A kockadobás kliens egyszerre két szabályos dobókockával dob, amit ezerszer megismétel és a dobott számok összegét datagram típusú üzenetküldéssel folyamatosan elküldi a szervernek. A szerver localhost-on fut és egy megadott porton keresztül várja a klienstől. A szerver és a kliens egyaránt szálkezelést alkalmazó konzolos alkalmazás.
A projektben van egy swing GUI-s alkalmazás, amely JFreeChart oszlopdiagramon – folyamatosan frissítve – megjeleníti az összesített adatokat, mindez a szerver üzenetküldésével irányítva (amint beérkezik egy dobott (2-12-ig) összeg).
A kommunikációnak – a lehetőségekhez képes – biztonságosnak és – a hálózati adatforgalmat tekintve – takarékosnak kell lennie! Ennek részeként szükséges egy azonosító és egy egyszerű szabály (protokoll).
Tekintsük át mondatszerűen a szálkezelést használó kliens és szerver kommunikációhoz kötődő feladatait:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
Kliens (háttérszálon): ciklus 1-től 1000-ig egyesével DatagramSocket létrehozása dobás1, dobás2, dobásÖsszeg előállítása üzenet előállítása //pl.: "12;kocka2#" DatagramPacket létrehozása üzenet elküldése a szervernek visszhang/log kiírása a konzolra DatagramSocket lezárása várakoztatás ciklus vége Szerver (háttérszálon): ciklus(végtelen) DatagramSocket létrehozása DatagramPacket létrehozása üzenet fogadása a klienstől DatagramSocket lezárása ha(valid az üzenet) akkor dobásÖsszeg feldolgozása ablak grafikonjának frissítése (GUI szálon) elágazás vége ciklus vége |
Ezek működését összefogja egy központi vezérlőosztály és ez a fejlesztőeszköz projektablakában így jelenik meg (egyetlen MVC Java projektként):
A program két felületen kommunikál. A háttérben konzolosan logol a kliens, és a háttérben futó szerver időnként frissítteti a grafikus felhasználói felületen (GUI, ablak) megjelenő grafikont:
Aki kedvet kapott: bátran készítse el a fenti terv/koncepció/specifikáció alapján az MVC Java projektet. Érdemes alaposan tesztelni: külön a szervert, külön a klienst, először indítva az egyiket, majd a másikat, leállítani az egyiket majd fordítva. Átgondoltan indokolni is hasznos, vajon mi, hogyan és miért történik.
A bejegyzéshez tartozó 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 1-8. óra: Elosztott alkalmazások, webszolgáltatások, szálkezelés, párhuzamosság alkalmához kapcsolódik. Amikor itt járunk a tananyagban, akkor a GUI felület és a grafikon tervezése, megvalósítása már magabiztosan megy, így elegendő a hálózati kommunikációra helyezni a fókuszt.
A forráskódot megnézve és persze az elméletet átrágva megértettem, hogy vannak blokkoló és nem blokkoló Socket alapú programok Javaban. Mivel ez most egy nem kritikus szerverhez való csatlakozás, így a példa a nem blokkoló változatot tartalmazza. Ezek szerint ezért nem pörög 100%-on a processzor a végtelen ciklus miatt?
Így van Károly, jól összeraktad fejben. A figyelés csak akkor reagál ebben az esetben, ha érkezik üzenet. A több szálon futó programoknál (vagy ha több program összehangoltan kommunikál) már többféle eset (üzenetfeldolgozási mód) adódhat. Más megközelítést találsz a
ServerSocketChannelés aSocketChannelosztályok működését bemutató mintaprogramunkban. Érdemes összehasonlítani.Köszönöm Balázs. Megnézem.
A datagram (UDP) nem garantálja a csomag megérkezését. Próbálgattam már ilyen programot és 100000 küldésnél már előfordult, hogy 1-2 csomag elveszett. Persze nem biztos, hogy ez a csekély hibaarány számít egy adatátvitelnél, de lehet, hogy kritikus. Tudom, hogy lecserélhető a datagram másra. Meg lehetne oldani a kommunikációt egy olyan programban, ami datagramot használ és MVC-s? Megbeszélhetjük ezt valamelyik következő órán?
Áron: igen és igen.
Egy egyszerű ötlet: ennél a programnál többutas kézfogás üzenetküldéssel összegyűjthetnénk, hogy a szükséges kockadobásból mennyi történt meg (“mennyi ment át”) és pótoltathatnánk a hiányzó dobásokat.
Balázs mutat majd a szombati órán 3 – iparban is használt – ötletet és folyamatokban gondolkodva végigköveti a csoport egy projekt forráskódjában böngészve a lehetőségeket a beavatkozásra. Algoritmusban kell gondolkodni, amivel felülről korrigáltatható egy rendszerben egy-egy alul lévő gyengébb láncszem.