EDA095 Nätverksprogrammering

Transkript

1 EDA095 Nätverksprogrammering Projekt Checkers Grupp 8, 2008 Dag Wahlberg <dag.wahlberg at gmail.com> Leo Barnes <nadir_ddt at msn.com> Erik Wallenborg <tf06ew4 at student.lth.se> Ylva Mellbin <tf05ym7 at student.lth.se> Handledare Pierre Nugues 16 maj 2008 LTH, Lund 107

2 Projekt i kursen Nätverksprogrammering - redovisning 1. Bakgrund Som projekt i denna kurs har vi konstruerat ett damspel (Checkers) som kan spelas grafiskt av två Användare som är ihopkopplade via en Server Det är ett s.k forcerat damspel, dvs en spelare måste (om detta är möjligt) ta motspelarens pjäs, vid varje tur. Servern kan hantera flera samtida spel. Till ett spel kan kopplas Obervatörer som endast kan se dragen. I spelet finns inbyggd chatt-funktion. Kod från tidigare uppgift om damspel (AI) har använts. 2. Kravspecifikation Grundkrav Det ska finnas flera klienter (spelare) men endast en server. En spelklient ska kunna presentera grafik, skicka och tolka text från servern samt göra drag. Servern ska kunna hantera uppkopplingar, skapa spelobjekt och hantera brädets interna representation, tolka kommandon från klienterna, avgöra om ett drag är giltigt, skicka spelets representation samt text till klienten, ange turordning, samt utse och meddela vinnare. Bland extrafunktionerna märks: att kunna göra drag grafiskt (drag & drop), en chatt mellan spelare, spel mot AI, att klient kan välja motståndare, att hantera fusk. 3. Modell Beskriv kortfattat de viktigaste klasserna och de trådar som finns i er modell. Beskriv sambandet mellan de olika klasserna, vilka datastrukturer som används, hur trådarna kommunicerar med varandra och vilken viktig information som skickas mellan klasserna/trådarna. Använd gärna figurer för att förklara. Serverklasser Server [Server] Grundläggande trådad klass som tar hand om alla nya anslutningar samt fungerar som ett Chatt-rum. Har funktionalitet för att låta Användare starta och gå med i ett Spel. Server-objektet innehåller förutom en lokal användarlista även den globala som förhindrar att flera Användare har samma namn. Innehåller en lista över alla aktiva Spel. Servern loggar all extern kommunikation till konsol och till fil, mha log4j. Då en ny anslutning tas emot i Server-tråden skapas en ny Användare-tråd som sedan har hand om all kommunikation med spelaren. command-metoden i Server-objektet kan hantera följande meddelanden från Användare: /quit: Koppla från Användare. /say: Skicka meddelande till alla Användare. /tell: Skicka meddelande till den egna Användare. /game: Skapa Spel (create) eller gå med i Spel (join), samt även lista alla Spel (list) 207

3 Spel [Game] Spelklass som förutom att fungera som ett Chatt-rum även har en intern dambrädes-representation samt metoder för spel. Innehåller en lokal användarlista. Varje Spel-objekt har ett unikt namn. Varje Spel-objekt tillåter två spelare (tas från de första två klienter som ansluter) samt oändligt många Observatörer. Spelet börjar först när två Användare anslutit sig. Om en spelare lämnar Spel-objektet innan spelet är färdigt så vinner automatiskt den andra spelaren på walk-over. Då alla Användare (spelare och observatörer) lämnat Spel-objektet tas det bort. Spel-objektet stöder i stort sett samma kommandon som Server-objektet med två viktiga skillnader: /move : Försöker göra det drag som motsvaras av message. /game: Om message motsvarar leave så lämnar användaren spelet och hamnar åter i Server-objektets chatt-rum. Bräde [CheckersBoard] Servern har en egen inre representation av brädet. Till detta används ett CheckersBoard-objekt som finns i varje Spelobjekt. Brädet representeras av en Integervektor med en specifik konvention för pjäser och rutor, och genom en rad olika metoder kan man bland annat utföra drag eller fråga vem vinnaren är. Genom dessa metoder hanteras även spellogiken. Ett dambräde kan representeras på minst 2 olika sätt. Det ena är att som i fallet med vårt CheckersBoard-objekt använda en så kallad "mailbox" representation. Man låter en vektor eller matris innehålla information om var varje pjäs befinner sig o.s.v.. Det andra alternativet som är mer komplicerat att programera är att använda sig utav bit-fält och genom att utnyttja bit-operatorer kunna förbättra prestandan. Dock är prestanda inte ett problem i detta projekt vilket gör att man hellre använder "mailbox" då denna är mer lätthanterlig. Förutom vissa standard metoder så som setboard() och getboard() finns även 3 huvud metoder som är både viktigare och mer komplicerade än de andra: >> boolean makemove(string, boolean): Själva hjärtat i klassen som använder en rad av olika dolda metoder. Dess uppgift är att tolka en textsträng som ett drag, utföra draget och sedan returnera True om det var ett giltigt drag alternativt False om antingen strängen eller draget var ogiltigt. Första steget är att genom ett antal olika kontroller verifiera att den sträng som skickas kan omvandlas till ett drag. Efter detta anropas den privata metoden ArrayList<int[]> movegen (int[], boolean) som returnerar en lista med alla möjliga drag. Det drag som angetts kontrolleras om det finns med på denna lista och om så är fallet utförs det. >> String getlastunvalidmove(): Vid de tillfällen som man får resultatet False från makemove() kan det vara väldigt frustrerande för spelaren att veta vad man faktiskt gjort för fel (vilket upptäcktes som irriterande under våra tester). Då är det bara att anropa denna metod som returnerar en förklaring. >> boolean haslost(boolean): Precis som namnet anger retuneras om en viss spelare har förlorat eller inte (vilket inträffar då en spelare inte längre har några drag kvar att göra). 307

4 Användare [User] En egen tråd som tar hand om all direkt kommunikation mellan klienten och servern genom ett TCP-socketobjekt. Då ett User-objekt skapas anropar det klienten och kräver ett unikt användarnamn. Klassen kontrollerar om användarnamnet är unikt genom att anropa Serverns globala användarlista. All data som ska skickas till en användare sänds i form av textsträngar genom metoderna sendtext(string message, User byuser) och sendtext(string message) som finns i User-klassen. Chatt-rum [ChatRoom] Ett interface som innehåller grundläggande metoder som måste implementeras i alla klasser tänkta att fungera som ett chatt-rum (i vårt fall Server och Game). Varje implementerande klass är tänkt att innehålla en lokal användarlista med alla Användare som för tillfället vill få meddelanden från detta Chatt-rum. Det är även tänkt att finnas en global användarlista i någon implementerande klass som håller reda på alla Användare i alla Chatt-rum. Alla Användare tillhör någon klass som implementerar ChatRoom. Den viktigaste metoden är command(string command, String message, User user) Så fort en Användare tar emot text från spelare så anropas command() i det Chat-rum som Användare för tillfället tillhör. Metoden tolkar och utför sedan kommandot. 407

5 Klientklasser Klient [GUIClient] Kopplar upp sig mot servern m.h.a. TCP och skapar sedan en inläsningstråd och ett grafiskt användargränssnitt för att hantera in- respektive utmatning. Grafiskt användargränssnitt [GUI] Klass som ärver Jframe. Innehåller dels ett chatt-fönster som låter användaren skicka meddelanden till och ta emot meddelanden från övriga användare i aktuellt chatt-rum. Då användaren inte är ansluten till något spel innehåller det även en lista över aktuella spel med möjlighet att ansluta sig till något av dessa eller skapa ett nytt. När användaren är ansluten till ett spel visas istället en grafisk representation av brädet (beskrivning se nedan). Grafiskt bräde [CheckersGraphics] Klass som ärver JPanel och visar en grafisk representation av dambrädet. Tillåter användaren att göra drag genom att klicka på pjäserna eller genom att skriva in draget i ett textfält. Skriver även ut vems tur det är. Klientens inläsningstråd [GUIClientInput] Tråd som läser in och hanterar meddelanden från servern. (Meddelanden till servern skickas direkt av det grafiska användargränssnittet eller brädet via klienten.) Klassen kan hantera följande kommandon från servern: /board: Uppdaterar det grafiska brädet. /user: Öppnar dialogbox för inläsning av användarnamn (request/exists) eller uppdaterar listan över användare. /game: Uppdaterar listan med Spel. Övriga meddelanden skrivs ut i chattfönstret. 507

6 4. Användarhandledning Först startas servern, sedan klienterna. Här förutsätts att den exekverbara koden finns tillgänglig i katalogen workspace/checkers/bin/ Starta servern gör man enklast inifrån utvecklingsmiljön (Eclipse) genom att köra Main med argumentet <portnr>, dvs Run As... Java Application.. osv Vill man starta servern från kommandoraden så gör man följande: $ cd Checkers/bin $ java -cp.:../vendor/apache/lib/log4j jar server.main /log4j.properties Det långa kommandot beror på att servern behöver hitta log4j-delarna. I detta exempel var portnr Servern skriver till loggfilen checkers.log samt till konsolen, vilket ska synas. Starta en klient genom följande kommando i lämpligt skal, givet samma placering av exekverbar kod som ovan. $ cd Checkers/bin $ java guiclient.guiclient localhost & Fyll i spelarnamn i dialogrutan som dyker upp. Du ska nu ha ett fönster utan spelplan. Betrakta stora vänstra rutan Games: Om det finns ett spel listat där, markera det och tryck Join-knappen Om det saknas spel, skapa ett genom att skriva namn på spelet t.v. om knappen Create o tryck sedan på den. Om du kommer fr o m tredje person så kan du antingen trycka Join för att gå med i det skapade spelet som observatör eller skapa ett eget spel med ett annat namn. Du ska nu ha fått upp en spelplan, med möjlighet att flytta samt lämna spelet. Meddelanden om spelet skrivs i den inbyggda konsolen längst upp. Titta i rutan för Users: finns två personer anslutna kan spelet börja, annars får du vänta tills någon annan spelare ansluter sig. När det finns två spelare syns det i konsolen ovan, se vilken färg din spelare har (Black eller White). Om det är din tur gör ett drag genom att klicka på från-rutan, sedan till-rutan och sedan trycka på Move. Är det ett korrekt drag så flyttas pjäsen, är det fel så skrivs meddelande i konsolen. Spelplanen uppdateras av den andre spelarens drag. Flytta när det är din tur. Detta är s.k. forcerat damspel, om du kan ta en eller flera pjäser så måste du göra det! Det går att få kung genom att nå motspelarens bakersta rad. Spela tills någon vunnit! Det går att chatta genom att skriva i den smala raden unner konsolen. Med Tell skickas meddelandet till den markerade användaren, med Say till alla anslutna Avsluta spelet genom Leave. Stäng klienten genom att stänga fönstret. 607

7 5. Utvärdering En sak som skulle kunnat göras bättre i server-delen är att det skapas en tråd för varje användare. Detta är slöseri med resurser då dessa trådar oftast bara väntar på att användaren ska göra något. Om klasserna och metoderna i java.nio.* hade använts istället hade detta kunnat lösas på ett mycket resurssnålare sätt. Då vi inte förväntar oss spelservrar med flera hundra användare är dock vårt program fullt tillräckligt för att lösa uppgiften. En annan möjlig förändring som kanske skulle förbättra programmet är om servern och klienten kommunicerade genom RMI. RMI anses dock vara ganska långsamt och kräver ofta en mycket större inledande jobbinsats i början vilket hade gjort projektet svårt att starta. ---lb Vi uppfyllde kraven väl, vi fick en del gratis från Eriks kod och dam-kunnande. Sockets var en bra lösning för nätverksdelarna, enklare än RMI. AI-delen kopplades aldrig in. Det hade varit mer realistiskt om klienten varit en webläsare, det hade varit lättare att distribuera, man kunde ha låtit folk testa spelet direkt på projektwebbsidan. Men då hade vi fått använda javascript, en webbserver, osv. Endast lite av dagens kod, spellogiken skulle gå att återanvända gissar jag, resten hade fått göras om. Inbyggda enhetstester tillsammans med acceptanstester tror jag hade förbättrat projektet en aning samtidigt som det gett alla större säkerhet att ändra var som helst i koden, inte bara i sin egen del. Acceptanstester hade kunnat fungera som "krav". Om man utvecklar testdrivet (TDD) så får man ju testerna på köpet, ev är det lite mer jobb när det är nätverkskod inblandat. Ingen stess- eller prestanadatester har genomförts. Att utveckla via gemensamt versionshanteringssystem (CVS) fungerade mycket bra. Kursen behöver absolut en projektuppgift, ett minus är möjligen att nätverks-delen riskerar bli liten totalt sett eftersom mycket annat ska ingå i ett färdigt system. Så maximalt med nätverksfokus på hela uppgiften. Det vore kul med något avslutande tävlingsmoment där man kunde testa sitt system mot andra eller mot någon anpassad "spelrobot". Poäng för användarvänlighet, snabbhet, stryktålighet eller liknande. Hade krävt att man enats om standardprotokoll för överföring, per spel. En nivå för godkänt, över det ger "ära". ---dw 6. Programlistor Vårt CVS-repository finns på /usr/local/proj2/eda095/cs08108 via t ex login-1.student.lth.se. 707