LectureMopp - Projekt i Nätverksprogrammering

Transkript

1 LectureMopp - Projekt i Nätverksprogrammering Anders Forslund (d04afr@student.lth.se) Anders Lund (et05al1@student.lth.se) Christopher Swanson (et05cs4@student.lth.se) 24 maj 2009

2 3 MODELL 1 Bakgrund När projektidéerna för vår grupp började diskuteras kom vi snabbt fram till att vi ville göra något som en användare kunde interagera med i sin webbläsare för i dagens IT-värld börjar allt fler applikationer flytta dit. Ett bra exempel är Eclipse som i nästa version skall kunna köras direkt i en webbläsare. Det spånades och spånades och resultatet blev idén att kunna streama film från föreläsningar tillsammans med ljud direkt i en webbläsare utan att behöva tanka ner en full applikation. Även en chatt skulle finnas tillgänglig för att kunna ställa frågor till föreläsaren. Tekniken som skulle användas var servlets med Java EE samt JSP. Efter en tid visade det sig att vi hade tagit oss vatten över huvudet. Vi gick inte ifrån idén att ha programmet i webbläsaren men löste det istället med en applet. Den kunde heller inte streama film eller ljud men däremot visa slides från föreläsningen. Chatten fanns även med. 2 Krav Eftersom vi mitt i projektet helt fick vända om (se Bakgrund) ändrades kraven ganska rejält. De slutgiltiga kraven blev enligt nedan: En klient (vanlig applikation) för läraren med chatt samt ett gränssnitt för att byta slide. En klient (applet för att fungera i en webbläsare) för eleverna med chatt samt ett gränssnitt för att se slides som lärarklienten styr. En server som styr allt. Flera klienter kan koppla upp sig mot denna. Trådsäkert. 3 Modell 3.1 Studentklienten När programmet skulle skrivas var det vår avsikt att skriva det enligt MVCmönstret, men vi tog beslutet att slå samman View och Controller vilket visade sig vara väldigt smidigt när man arbetar med en applet som inte behöver en avancerad controller. Appleten använder sig av swing och observerar modellen. Den enda input som finns i programmet är texten användaren skriver och knappen som skickar så behövs det endast en controller som består av en egenskriven actionlistener. Modellen består av tre klasser. Två står för nätverkskommunikationen, där sender är en klass med metoden send och receiver är en tråd som hämtar packet. ClientModel sköter all logik till exempel handshaking samt behandling av packet. 2

3 3.2 Lärarklienten 3 MODELL 3.2 Lärarklienten Lärarklienten är till skillnad från studentklienten en vanlig Java-applikation. Den använder sig av model-view-controller och observermönstrena. Klienten kan befinna sig i tre olika states, samma states som servern använder: unconnected, connected och connected to session. Som input tar applikationen från användaren loginuppgifter, chatmeddelanden och tryckningar fram och tillbaka för slidesen. Från servern tar den meddelanden enligt protokollet som är utvecklat för projektet. När slides i form av jpeg-bilder ska visas så skickas de först till en klass som skalar ner dem till lämplig storlek. 3.3 Servern Mellan studentklienten och lärarklienten finns servern. Den är uppbyggd kring två monitorer. En monitor, ServerMonitor, innehåller all information om serverns och dess sessioners status. Den ansvarar även för de meddelandeköer som väntar på att behandlas. Den andra monitorn, ConnectionHandler, ansvarar för alla anslutningar och kommunikation. Servern innehåller två trådar som behandlar meddelanden, en för chatmeddelanden och en för signaleringsmeddelanden. Upplägget med två trådar gör att chatmeddelanden alltid snabbt vidarebefordras fast det exempelvis pågår processer som tar längre tid i anspråk. Utöver det så finns det en mottagartråd till varje ansluten klient. 3.4 Protokollet Protokollet består av tre fält. Det första, TYPE, Används för att avgöra ifall det rör sig om chatmeddelanden eller signaleringsdata. Är ett chatmeddelande så innehåller det andra fältet till vilken session meddelandet ska sändas och det tredje fältet själv chatmeddelandet. Anger TYPE-fältet signaleringsdata så följs det av fältet SUBTYPE som innehåller vilken typ av signalerningsdata meddelandet innehåller. SUBTYPE som är en int är indelat i två grupper innehåller förfrågningar eller information som pushas och som innehåller svar på den förra gruppen. Det sista fältet innehåller data TYPE SUBTYPE DATA TYPE SESSION MESSAGE

4 4 ANVÄNDARHANDLEDNING 4 Användarhandledning 4.1 Elevklient Markerat med nummer 1 i figuren ovan är området där eleven ser den aktuella slide:n som läraren har valt. Textrutan markerad med nummer 2 fungerar först och främst som ett gränssnitt för att koppla upp sig mot mot en server och föreläsning. För att göra detta skriver man ip;port;namn;session där ip är ipadressen till servern, port är porten servern är startad på, namn är ditt valda användarnamn och session är namnet på en specifik föreläsning. Därefter trycker man på knappen markerat med nummer 3 i figuren. Om allt har gått som det ska fungerar nu textrutan istället som en chattruta där man kan förmedla vad man vill ha sagt till föreläsaren och andra uppkopplade elever. 4

5 4.2 Lärarklient 5 UTVÄRDERING 4.2 Lärarklient När lärarklienten startas bestämmer man först vad man ska ha för användarnamn (nummer 1 i figuren) samt vad föreläsnings-sessionen ska heta (nummer 2). I textrutan markerat med nummer 1 i figuren ovan kan läraren se chatten där eleverna ställer frågor. I rutan bredvid (nummer 2) kan han/hon svara. Aktuell föreläsnings-slide visas i området markerat med nummer 3. För att byta slide används knapparna Next och Previous. 5 Utvärdering När vi ska utvärdera projektet är det svårt att vara riktigt nöjd. Vår ursprungliga idé fungerade inte alls. Ribban hade lagts alldeles för högt och även om vi själva anade detta till en början gav vi det ett försök och det tycker jag ändå vi gjorde rätt i. Ibland måste man chansa. Tröskeln till exempelvis Java EE var alldeles för hög och det tog oss flertalet timmar bara att få igång en fungerande Hello World!. 5

6 6 KÄLLKOD När vi väl kommit in på vår nya bana med den nya idén flöt arbetet på relativt bra och inga direkt stora problem uppstod. Dock lyckades vi aldrig få igång vår elevklient som en applet i webbläsaren utan endast i Eclipse egna appletviewer. I vår kod-design använder vi oss av mönstret Model-View-Controller vilket gör att våra program är väldigt lätta att komplettera och bygga vidare på. Denna lösning valde vi med anledning av osäkerheten i vår idé från början. I slutändan visade det sig vara ett väldigt bra beslut eftersom många timmars arbete kunde sparas in när den ursprungliga idén skulle skrotas. Sammanfattningsvis kan man säga att trots omständigheterna är vi relativt nöjda med slutresultatet. Vi hade förväntat oss mer av oss själva men vi har tagit lärdom och vet nu att planer inte alltid går som man vill. GUI-design är även något som vi kanske behöver jobba på. 6 Källkod Källkoden kan hittas på: 6