. .. : Swf.hu 1.0 archívum : Swf.hu főoldal >>> : .. .




 
 
SEGÉDLETEK Flash+Java

SimpleChat V1.0 - Flash-Chat alkalmazás készítése (JAVA)
  feltöltve: 2004.02.02 | szerző: tenegri | olvasva: 11798 alkalommal

       
 

Szint: haladó Alkalmazás: Flash MX 2004 ActionScript: AS2

A fórumban időnként feltűnő kérdések alapján valószínűleg sokakban felmerült már az igény, hogy egy Flash alapú chat-et készítsenek. Ebben a segédletben ezt próbáljuk megvalósítani egy egyszerű, egyszobás chat formájában, amit egyszerűen használható és beilleszthető formában, komponensként készítünk el. A segédlet nem csak a kliensoldali részre, hanem a szerveroldali megvalósításra is kiterjed.

Mivel a segédlet viszonylag hosszú lesz, az érdeklődés és a kitartás kellő felpumpálásához legelőször is nézzük meg a végeredményt. Alul a képen láthatjuk hogy is néz ki a kezelőfelület, s erre a linkre kattintva működés közben is megtekinthetjük (az egyetlen eltérés a segédletben leírt chat programhoz képest, hogy a megadott linken található változat loggolja a felhasználók ki- és belépését - csak hogy tudjam hányan próbálták ki :)).

Elöljáróban még megjegyezném, hogy a mellékelt fájlok zip archívumként és Macromedia Extension-ként (.mxp) is letölthetők, tartalmuk megegyezik, de az extension-t egyszerűbb használni, mert az Extension Manager segítségével egy mozdulattal telepíthető és minden a helyére kerül (így semmit nem kell kézzel másolgatni).

Egy kis elméleti háttér

Egy chat program két részből áll: egy szerveroldali és egy kliensoldali részből. Az előbbi tartja nyilván a belépett felhasználókat, s ez végzi az üzenetek szétküldését, míg az utóbbi jeleníti meg a szervertől kapott üzenetek alapján a voltaképpeni csevejt, s ez továbbítja a szerver felé a többi felhasználó számára küldött üzeneteket. A kliens és a szerver közti kapcsolatot tekintve alapvetően kétféle megoldás létezik:
• a kliens rendszeres időközönként felveszi a kapcsolatot a szerverrel, lekérdezi az új eseményeket (pl. érkezett-e új üzenet), majd bontja a kapcsolatot, illetve hasonlóan jár el, ha ő szeretne a szerverrel közölni valamit (új üzenet küldése)
• folyamatosan nyitva tartott kapcsolat, melynél a szerver és a kliens csak akkor küld adatot a másik felé, ha valami esemény történt (új üzenet érkezett, belépett/kilépett egy felhasználó, stb.), így ez lényegesen kisebb forgalommal jár, nem is szólva róla, hogy a kapcsolatot is elég csak egyszer felépíteni.

Az első megoldás előnye, hogy egyszerű HTTP lekérésekkel megvalósítható, így az adatforgalom könnyen átmegy a tűzfalakon, s a szerveroldali programmal CGI interfészen keresztül vagy webszolgáltatásként lehet kommunikálni, amihez elegendő a legtöbb tárhelyszolgáltató által biztosított jog a CGI programok futtatásához. Hátránya, hogy a folyamatos kapcsolat hiánya miatt az üzenetek némi késéssel érkeznek meg a kliensekhez, valamint a kapcsolat újra és újra történő felépítése nagyon időigényes, s jelentős erőforrásokat és sávszélességet köt le a szerveroldalon, s sokszor a kapcsolatfelvétel voltaképpen felesleges is (nem érkezett új üzenet). Természetesen ez 1-2 felhasználónál még nem jelent problémát, de nagyobb számú aktív chat-elő már komoly terhelést okozhat, akár felérhetnek egy kisebb DoS (Denial of Service) támadással, s ez főleg olyan gépeknél gond, melyek pl. sok weboldalt szolgálnak ki (ilyenek az ingyenes, de a fizetős tárhelyet biztosító szolgáltatók szerverei is).

A második lehetőség már sokkal erőforrástakarékosabb és rugalmasabb, azonnal értesülhetnek a kliensek az eseményekről. Megvalósítható TCP vagy UDP socket felhasználásával, viszont szükség van hozzá egy olyan szerverre, amelyen van jogunk programok futtatására. Továbbá gond lehet a tűzfalakkal, hiszen a kommunikációra használt portnak engedélyezve kell lennie, ám ez sok esetben (főleg céges környezetben) biztonsági okokból nincs így.

Mi a kis chatprogramunkhoz a kommunikáció utóbbi módját választjuk, s TCP socket-en keresztül bonyolítjuk az adatforgalmat.

Egy chat program szerver- és kliensrészét számos programnyelvvel és eszközzel elkészíthetjük. Mint azt valószínűsíteni lehet, jelen esetben a kliensrészt Flash-sel valósítjuk meg, de még mindig kérdéses a szerverprogram megírása. Ha nem a folyamatos kapcsolatot választottuk volna, akkor jó megoldás lehetne a PHP használata, hiszen szinte minden szerveren elérhető, platformfüggetlen, s könnyen kezelhető nyelv. Mi viszont TCP socket-et választottunk, így - bár ez is megoldható PHP-val, de ezért mindenki érzi, hogy az nem az igazi :) - nézzünk más után. Ha tudjuk milyen OS fut a szerveren választhatunk platformfüggő fejlesztőeszközt is (akár még Delphi-t vagy Visual Basic-et is), de valószínűleg jobban járunk ha platformfüggetlen megoldást keresünk: C++ (na jó, ez nem mindig platformfüggetlen), Java, Python, stb. Az én választásom a Java-ra esett, mert könnyen kezelhető felületet biztosít a socket-ek használatához, egyszerű szálkezeléssel rendelkezik (ez jól jöhet több felhasználó egyidejű kiszolgálásakor), szinte minden platformon elérhető, s még a Unicode-dal sincs gondja, ami figyelembe véve a Flash Unicode-os szövegkezelését, nem utolsó szempont.

Feladatleírás

Tisztáznunk kell mire is vállalkozunk, azaz milyen funkciókkal és lehetőségekkel bíró chat-et készítünk. Megpróbálom minél átláthatóbbra készíteni a programot, ezért szorítkozzunk csak a legalapvetőbb szolgáltatásokra:
• nincs szükségünk több szobára, egy helyen zajlik a társalgás
• a felhasználók megadhatnak egy nevet, amivel belépnek (a regisztrációt most mellőzzük)
• jelezze ki, ha belép vagy kilép valaki
• le lehessen kérdezni a belépett felhasználók listáját

Ezek már elegendőek a chat-eléshez, a forgalmasabb chat oldalakon megszokott kényelmi szolgáltatásokkal pedig mindenki saját igényei szerint bővítheti majd a programot.

A kommunikációs protokoll

Az üzeneteket a szerver és a kliensprogram között XML "dokumentumok" formájában fogjuk továbbítani. Ennek egyrészt megvan az az előnye, hogy mind az ActionScript, mind pedig a Java jól támogatja, másrészt pedig rugalmas lehetőséget biztosít a szolgáltatások esetleges későbbi bővítésére, anélkül, hogy egy saját adatformátumot kellene kitalálnunk, s ahhoz értelmezőt készítenünk.

A chat-ünk működése során a következő üzeneteket használja:

Kliens -> szerver üzenetek

LOGIN
Belépés a chat-re és a felhasználónév megadása. A login kérésre válaszul a szerver egy STATUS üzenetet küld, hogy sikeres volt-e a belépés. Pl.:
<LOGIN>Sanyi</LOGIN>
MESSAGE
Új üzenet küldése. Attribútuma nincs, a nyitó- és a záróelem közti szöveg az üzenet. Pl.:
<MESSAGE>Ez itt egy üzenet...</MESSAGE>
GET_USER_LIST
Felhasználók listájának lekérése. Nincs attribútuma. A szerver válaszát a USERLIST üzenetben küldi. Pl.:
<GET_USER_LIST />
CLOSE
Kilépés a chat-ről. Nincs attribútuma. Pl.:
<CLOSE />

Szerver -> kliens üzenetek

STATUS
Új üzenet érkezett. A CODE attribútum adja meg hiba kódját, míg a nyitó- és záróelem közti szöveg az emberibb nyelvű üzenetet tartalmazza. Pillanatnyilag a következő hibakódok használatosak:
100
Kerülj beljebb xy! Köszöntünk a chat-en!
101
Nem értelmezhető a bejelentkező üzenet!
102
Van már ilyen néven belépett felhasználó vagy nincs megadva felhasználónév!
103
Nem értelmezhető XML üzenet érkezett a klienstől.
104
Ismeretlen típusú üzenet érkezett a klienstől.
Pl.:
<STATUS CODE="103">Nem értelmezhető XML üzenet.</STATUS>

MESSAGE
Új üzenet érkezett. A SENDER attribútum adja meg az üzenetet küldő felhasználó nevét, míg a nyitó- és záróelem közti szöveg az üzenet. Pl.:
<MESSAGE SENDER="Petike">Ez itt egy üzenet...</MESSAGE>
USER_CONNECTED
Új felhasználó lépett be. A NAME attribútum tartalmazza a felhasználó nevét. Pl.:
<USER_CONNECTED NAME="Petike" />
USER_DISCONNECTED
Egy felhasználó kilépett. A NAME attribútum tartalmazza a felhasználó nevét. Pl.:
<USER_DISCONNECTED NAME="Petike" />
USER_LIST
A felhasználók listája. A felhasználók nevei a USER elem NAME attribútumában szerepelnek. Ez az üzenet a klienstől érkezett GET_USERLIST kérésre válasz. Pl.:
<USER_LIST>
  <USER NAME="Józsi" />
  <USER NAME="Feri" />
  <USER NAME="Aladár" />
</USER_LIST>

A kommunikációs protokollunkról még annyit érdemes elmondani, hogy a jelen segédletben megvalósított chat szerver és kliens program egyaránt csak nagybetűs formában értelmezi a fenti XML elem - és attribútumneveket, ha ettől eltérőek, akkor hibát jeleznek. Mindez csupán amiatt van, mert az XML kezelésben (és általában véve máshol is) a Java és a Flash MX 2004 egyaránt megkülönbözteti a kis- és nagybetűket, s egyszerűbb volt így megoldani, mint külön kóddal kibővíteni a programot, amely megszünteti ezt a megszorítást, de a segédlet szempontjából csak felesleges bonyolítás lenne (igazából az elemnevéknél ez minimális bővítés lenne, az attribútumoknál már némileg több).

 
       
 
 

© Devnet.hu. A segédletek semmilyen formában nem másolhatók, publikálhatók a Devnet.hu és a szerzők közös írásos engedélye nélkül.
 
. .. : Swf.hu 1.0 archívum : Swf.hu főoldal >>> : .. .