Tom side til prosjekt beskrivelse.

Transkript

1

2 Tom side til prosjekt beskrivelse. 2

3 Hovedprosjekt datateknikk, Våren Tittel: Deltakere: Veileder: Ip-telefoni. Robert Rinnan, Morten Sundstrøm, Vegard Slettedahl. Hans Jørgen Alker. Sammendrag Som prosjekt tittelen indikerer, omhandles tale overføring fra en pc til en annen, ved hjelp av overføring av data, over internett. Dette prosjektet omhandler en klient del, og en server del. Klientene logger seg på serveren ved hjelp av TCP/IP protokollen, og bruker SSL kryptering. Klienter som er logget på serveren kan koble seg direkte til hverandre ved tekst sesjoner (TCP/IP SSL kryptering), eller tale sesjoner (UDP/IP). Programmerings språket er Java. Forord Denne oppgaven er rettet mot personer med programmeringsbakgrunn i Java. De som leser dette dokumentet bør også ha en viss forståelse for nettverk, og nettverks programmering. 3

4 INNLEDNING...5 MOTIVASJON...5 PROBLEMSTILLING...5 BESKRIVELSE AV PROGRAMMET VED PROSJEKTSTART...6 BAKGRUNN...6 MØTEVIRKSOMHET...7 DELMÅL/FREMDRIFTSPLAN...7 KRAV TIL DATAMASKIN...7 JAVA...8 TEXTPAD...9 GENERELT OM IP-TELEFONI...10 GENERELT OM IP...10 OVERBLIKK...11 GRAFISK GRENSESNITT...13 SESSIONER OG NAT...16 TEKST SESSIONER...18 VOICE SESSIONER...18 KOMMANDOER...19 ADD BUDDY...19 DEL BUDDY...20 PROBLEMER VEDRØRENDE LYDEN...21 FULL OG HALV DUPLEX...22 LYDKVALITET OG FORSINKELSE...22 SIKKERHET...23 TESTING AV PROGRAMMET...25 KONKLUSJON...25 ERFARINGER...26 VIDEREUTVIKLING...26 KILDER...26 VEDLEGG

5 Innledning Prosjektet er valgt ut fra eget initiativ, og har vært påtenkt siden første året ved Høgskolen i Vestfold. Oppgaven er å overføre tekst sesjoner og samtaler via ip. Motivasjon Temaet Nettverk og overføring av informasjon, faller interessant for alle deltakerne i gruppen. Vi ønsker å utvikle vår kompetanse, både innenfor nettverk og programmering. Intranett blir bare mer og mer brukt blant større bedrifter, men intranett løsninger tilbys også til mindre bedrifter som ikke ønsker å drifte sitt eget intranett. For å øke kunnskap rundt intranett ønsker vi å få en litt stødigere bakgrunn i nettverks programmering. Vi er motivert til å lære oss om kommunikasjon ved hjelp av TCP og UDP for å få ett innblikk i hvordan klient/server kommunikasjon foregår. Temaet er høyaktuelt blant bedrifter i næringslivet, og dette vil nok styrke våre sjanser på arbeidsmarkedet. Sann tids overføring av lyd er stadig under utvikling, og vi ønsker å være en del av denne teknologien. Problemstilling Prosjektets målsetting er å kunne kommunisere over et nettverk av flere datamaskiner. Kommunikasjonen skal foregå skriftlig eller muntlig. Programmet skal ha en lett forståelig GUI, slik at man ikke skal trenge å ha så mye datakunnskaper for å bruke det. Programmet skal være tilgjengelig for alle plattformer som støtter Java. Man skal ikke være avhengig av å kjøre Windows for å bruke det. Ingen av oss har spiss kompetanse innenfor Java programmering, men vi innehar generell kunnskap om nettverk og hvordan server/klient kommunikasjon skal foregå. Nye elementer for oss: - Nettverks programmering. - SSL kryptering. - Fil behandling. - Lyd behandling. - Swing komponenter. Dette er store tema, og det vil by på utfordringer å sette seg inn i dette, samtidig med at programmering og rapportskriving skal foregå. Valget av Java som programmerings språk, grunnlegges ved at programmet skal være plattform uavhengig. Dvs. programmet skal kunne kjøres på forskjellige operativsystemer. 5

6 Beskrivelse av programmet ved prosjektstart. Dette er en kort forklaring på hvordan kommunikasjonen skal foregå, og hvordan programmet fungerer. Prosjektet har to deler. En serverdel og en klientdel. Serverdelen skal ta for seg alle klientene som er brukere av programmet. Lagre og holde styr på de dataene som ankommer serveren. Hver klient har et brukernavn og et passord. Brukernavnet skal bestå av en unik e-post adresse. For å skille brukerne, vil hver bruker ha sin egen fil på serveren som har et filnavn tilsvarende brukernavnet deres. F.eks. I denne filen vil all informasjon om denne brukeren ligge. Når en bruker da logger seg opp mot serveren vil den informasjonen bli sjekket opp mot den filen. Skulle det være noe som gjør at denne brukeren ikke er den han utgir seg for å være, vil han motta en feilmelding. Serveren skal ikke ta seg av kommunikasjonen mellom brukerne, kun i mellom bruker og server. Klientdelen skal vise en grafisk presentasjon av programmet som skal være enkelt å bruke. Programmet skal håndtere innlogging/avlogging og kommunikasjonen mellom brukerne. For å kunne få kontakt med andre brukere må disse legges til i brukerens liste. Denne listen skal vise om de andre brukerne er online eller offline. Når en bruker legger til en annen bruker må det godkjennes av den brukeren før de kan oppnå kontakt med hverandre. Når dette er gjort vil de kunne opprette en samtale med tekst eller sanntidsoverføring med tale. Bakgrunn Hva kan prosjekt gruppen om Java? 1/15 del av studiet (4 vekttall), har vært Java programmering. Den generelle oppfatningen i gruppen er at Java er enklere enn for eksempel C/C++. Når vi har programmert gjennom studiet har vi hatt fokus på objekt orientert programmering, og det vi har tilegnet oss i andre programmerings språk, kan også brukes i Java. Studiet har et meget bra tilbud innenfor nettverk, den kunnskapen vi har tilegnet oss der, og gjennom egen interesse, blir helt sikkert nyttig. Ideen om et program som kan overføre tale på en skikkelig måte, ble født for ca. 3år siden. Tanker rundt programmet har surret gjennom studiet. Når rammebetingelsene for prosjektet skulle settes, måtte gruppa bli enige om størrelsen av prosjektet. Vi har begrenset prosjektet en hel del når vi tenker på hvilken funksjonalitet vi kunne ha tenkt oss. Det er ikke tvil om at temaet er høyaktuelt, og prosjektet har et enormt utviklings potensial. 6

7 Møtevirksomhet Siden vi ikke har hatt en oppgave med ferdig definerte rammer gitt fra en ekstern bedrift eller lignende. Føler vi att vi har stått ganske fritt. Gruppen har møtt hverandre på en daglig basis så fremt ikke annet har vært avtalt. Møter med veileder har skjedd ukentlig, og etter behov. Disse møtene har tatt for seg framdriften på prosjektet for å sikre at prosjektet kom i havn. Delmål/fremdriftsplan Fremdriften var tydelig etter hvert som klassene ble utviklet. milepælene, kan sees i fremdriftsplanen (Vedlegg 1). Server og klientdel ble utviklet hver for seg på et basisk nivå, men utviklingen ble samkjørt mer og mer etter hvert som funksjonalitet ble lagt til. Delmål kort oppsummert: - Klient. - Server. - TCP Kommunikasjon. - Lagring av data til fil. - Sikker overføring av meldinger (SSL). - UDP Kommunikasjon. For å sikre at alle i gruppa fikk tilnærmet likt utbytte av prosjektet, ble det i fellesskap bestemt at all jobbing på prosjektet skulle foregå i fellesskap. Dette har fungert slik at vi har sittet samlet hjemme hos en av oss, avhengig av hvor det har passet best å sitte. Større problemstillinger som klient/server kommunikasjon, lagring til fil og andre større ukjente tema, har vi forsøkt å utvikle i fellesskap, andre lettere oppgaver har vi forsøkt så godt det lar seg gjøre å fordele likt mellom gruppe medlemmene. Krav til datamaskin Datamaskinen må være koblet til et nettverk, enten et lokal nettverk eller Internet. Hvis programmet skal kunne brukes på et lokal nettverk må serveren være koblet på det samme nettverket. Får å kunne bruke sanntids overføring med lyd må brukeren ha lydkort og hodetelefoner med mikrofon. Programmet har vært testet med lydoverføring over Internettet med en hastighet på ca 128kbit. Dette tilsvarer ca dobbel ISDN hastighet. 7

8 Java Java ble som nevnt fordi programmet skal være plattform uavhengig, men Java er også rettet mot nettverk, og nettverksprogrammering. Java som verktøy viste seg å være fleksibelt, og enkelt å bruke. Dynamikken i Java SDK en er grei og oversiktelig. SDK og det man trenger for å komme i gang med java kan lastes ned gratis på Sun s hjemmesider: Dette må sies å være noe av styrken til Java, det finnes mengder med informasjon som kan brukes gratis. Java s biblioteker er oversiktelige å enkle å søke i. Java er objektorientert! Dette dokumentet tar ikke for seg hva objektorientert programmering er, men kort sagt gjør Java, på lik linje med C++, det mulig å ta i bruk klasser, og unngå prosedyre programmering. Da Together v.6.01 ikke støttet den nyeste SDK en, valgte vi å bruke Textpad når vi programmerte. Fordelen ved å bruke enkle utviklings verktøy, er at du unngår en del forhånds generert kode, og du mister ikke oversikten. De som har prøvd seg på programmering innenfor MFC, vet at det er en del koding for å få til et Window, og det genereres en hel masse med overhead informasjon. I Java bruker man Frames. En frame er egentlig ikke annet enn en liten konteiner tilsvarende et Window, der du kan sette inn den informasjonen du vil. Følgende er et eksempel på hvor lett en frame kan opprettes class ShowFrame extends JFrame { private static JFrame frame; private JLabel label; private Container container; ShowFrame() { label=new JLabel("Frame input!"); container=getcontentpane(); container.add(label); settitle("showframe"); setsize(150,100); setvisible(true); validate(); } public static void main(string[] args) { frame = new ShowFrame(); } } 8

9 Textpad Textpad er vårt valg av tekst editor. Eksempel på typisk arbeidsskjerm: Textpad er ingenting annet enn en enkel text editor med mulighet for å legge til kommandoer som for eksempel compile, run, osv. Textpad tilbyr ett enkelt og ryddig arbeidsområde. At oppsettet er ryddig har alt å si når man skal holde orden på så mange filer på en gang. 9

10 Generelt om Ip-Telefoni IP telefoni er en generell betegnelse for teknologien som bruker et IP-datanettverk for å opprette forbindelser mellom brukere for overføring av lyd, video, fax og andre lignende tjenester. Ip telefoni benytter et IP-datanettverk til telefoni, noe som betyr at man ikke trenger å koble seg til det eksterne telefon nettet for å ha en samtale. UDP pakker med lyd sendes til og fra klienter. Klient 1 Klient 2 Generelt om IP Internet Protocol (IP) er metoden eller protokollen som benyttes når data sendes fra en datamaskin til en annen. Hver datamaskin som er koblet til Internet har minst en IP-adresse, en unik id, som er forskjellig fra alle andre datamaskiner på Internet. Når man sender eller mottar data (for eksempel, en e post: eller en Web side), blir budskapet delt inn i små biter kalt pakker. Hver av disse pakkene inneholder avsenderens Internet adresse, mottakerens adresse og dataene som representerer det man skal ha tak i. Pakken sendes først til en gateway som forstår en liten del av hvordan sin tilknytning til Internet er. Gateway n leser destinasjonsadressen og sender pakken til en tilsvarende gateway. Pakken tar så turen videre til den kommer innenfor det domenet adressen er registrert i. Den gateway n sender da pakken direkte til datamaskinen hvis adressen er spesifisert. Når man streamer lyd og video over nettet brukes en protokoll som heter UDP. Denne protokollen har ikke feilsjekk noe som kan by på en del problemer. Når pakkene blir sendt så er det ikke sikkert pakken ankommer adressen i den rekkefølgen de ble sendt i, det er heller ikke sikkert at pakken kommer fram i det hele tatt.. Det kan da oppstå hakking/spraking i lyden eller bildet. Som regel går dette bra. Fordelen med det er at pakken ikke trenger tilbakemelding på at den er mottatt slik at overføringen kan skje i sanntid. Slik Internet er bygd opp i dag så kan det ta lang tid å sende slikke pakker over store avstander som igjen vil medføre forsinkelse i lyden. 10

11 Overblikk Programmet består av en server som skal behandle alle klienter som logger seg på. For å logge seg på serveren, må klienten først opprette en brukerkonto. Når kontoen er opprettet og klienten er logget på vil klienten og serveren kunne kommunisere med hverandre gjennom kommandoer. For klienten vil kommunikasjonen oppfattes slik. (Klient flowchart) Log on No Exsisting user? Yes Create new user Log on exsisting user Log on as new user if(!logged on) If(logged on) If(logged on) Client GUI Serverlistener Step1: Klienten prøver å logge seg på serveren, enten som en eksisterende bruker, eller som en ny bruker. Step2: Hvis alle kriterier for å logge på serveren er oppfylt, logges klienten på serveren. Hvis det oppstår en feil må klienten gå til step 1. Step3: Lytt til meldinger fra serveren. Serverlistener er den delen av klienten som lytter etter beskjeder fra serveren. 11

12 For serveren vil kommunikasjonen oppfattes slik. (Server flowchart) Listen for connections Connected to server If(New user) Exsisting user? If(Exsisting user) If user already created No Yes Send error reply to client Deny logon No Does user exsist? correct password? if(already logged on) {log off user; log in user;} else log in; Create file Logged on Notify buddies Listen for commands the from client Step1: Lytt etter nye klienter som vil logge på serveren. Step2: For nye brukere, opprett brukeren. Step3: Hvis alle kriterier er oppfylt, logg på brukeren. Step4: Gi beskjed til alle buddies om påloggingen. Step5: Lytt for kommandoer fra klienten. Klienter som er logget på serveren gir beskjed til hverandre om de er online eller offline, så lenge klientene har addet hverandre. 12

13 Overføring av både tekst og lyd, foregår direkte mellom klientene. Client1 Client2 Tekst, Lyd Alle andre kommandoer, som f. eks om en klient er online eller offline, går gjennom serveren. Man må gå gjennom serveren for å få kontakt med andre klienter Grafisk grensesnitt Klient delen av programmet har grafisk grensesnitt, og en klient vil bli møtt med 3 valg ved oppstart av programmet. Valgene er egentlig selvforklarende, og det gis bare korte kommentarer. Valg1: For den siste som var logget på serveren fra denne maskinen. Valg2: Hvis man ønsker å bytte bruker. Valg3: Hvis man ønsker å opprette en ny bruker. Log on as default. Change user. Create new user. 13

14 Hvis alt går greit med innlogging, blir klienten møtt med dette vinduet ved første gangs innlogging. Dette er klientens grafiske grensesnitt, når man er logget på serveren. Meny valgene: Close lukker programmet. Show system info, henter fram informasjonen om systemet, og java versjon. 14

15 About, henter fram informasjon om programmet. Add contact, brukes når man skal legge til buddies. Online buddy, vises med grønn. Offline buddy, vises med rød. En buddy, som er online kan man starte en text, eller voice session med. Man kan også slette en buddy, uavhengig av om buddyen er online eller offline. 15

16 Tekst session. En tekst session kan startes enten ved å dobbelt klikke på en online buddy, eller ved å høyre klikke og velge tekst session. Voice session. En voice session har en egen ramme, med egne valg. Som Stop indikerer, stopper et trykk på denne knappen samtalen, man kan også Mute samtalen. Når man Mute r en samtale kan man fortsatt høre den man snakker med, men den man snakker med kan ikke høre deg. Sessioner og nat Hva er nat? Network address translation gjør en router i stand til å fungere som en agent mellom internett (eller public nettverk ) og et lokalt ( privat ) nettverk. Dette betyr at bare en unik IP adresse er nødvendig for å representere en hel gruppe maskiner. Bruken av dette programmet krever at brukerne har unike globale ip-adresser. Så lenge server delen av programmet kjører på en global ip-adresse, vil man uansett få kontakt med serveren. Dette er på grunn av TCP\IP- protokollen. 16

17 Ip-phone SERVER Global IP Internett Global IP Klient 1 Lokal IP Router 1 Forbindelsen mellom klienten og serveren opprettes av klienten. Når klienten logger seg på serveren, opprettes det en forbindelse (tunnel) mellom klient og server ved hjelp av TCP. Dette gjør at klienten kan sende innformasjon til serveren, og serveren kan også sende innformasjon tilbake til klienten. I dette tilfellet vil routeren videresende pakkene som kommer fra serveren til klienten. Det som imidlertid blir oppfattet av serveren som klientens ip-adresse, er den globale ip-adressen til routeren. Vi introduserer en ny klient på et annet lokal nettverk i modellen vår. Klient 2 Router 2 Lokal IP Ip-phone serveren vil også oppfatte klient 2 s ip-adresse som router 2 s globale ip-adresse. Hva skjer da når klient 1 og klient 2 skal kommunisere? I ett tenkt tilfelle prøver klient1 å kontakte klient2. Forbindelsen feiler fordi klient1 prøver å opprette en forbindelse med routeren til klient2. Vi tenker oss en annen situasjon der klient 3 har en global ip adresse. Klient 3 17

18 Nå kan alle klienter som er bak en router opprette en TCP forbindelse med klient3, kommunikasjonen mellom klientene vil da fungere. Hvis derimot klient3 forsøker å kontakte klienter som sitter bak en router, vil ikke dette fungere, fordi klient 3 vil forsøke å opprette en forbindelse på ip-adressene til routerene. Løsning. Løsningen på dette problemet er å lage en session server. Introduksjonen av en sessions server ville sørget for at serveren ville ha videreformidlet alle beskjeder mellom klientene. I de tilfeller der routeren er en pc, er det også mulig å opprette en applikasjon på routeren som videresender pakkene dit de skal på lokal nettverket, f.eks en proxy server. Vi går ikke videre inn på port forwarding og lignende, men mulighetene for å løse problemet begrenses kun av fantasien. Tekst sessioner Slik vi utformet serveren, formidles kommandoer via serveren mellom klientene. Tekst sessioner derimot, foregår direkte mellom klientene. Klient Klient Komunikasjon TCP/IP Denne måten å kommunisere på innebærer at brukere av programmet, må selv ta høyde for kommunikasjons problem. Voice sessioner Kommunikasjon ved hjelp av tale (voice), opprettes direkte mellom klienter, og krever også globale ip-adresser. Klient Klient Kommunikasjon UDP/IP Hvorfor UDP? UDP er en forbindelsesløs kommunikasjon, og pakkene som inneholder en tabell med bytes (som representerer lyden), sendes mellom klientene uten å få bekreftet at pakkene kommer fram. UDP genererer mindre heading informasjon enn TCP, og valget begrunnes med at mengden av innformasjon som sendes må begrenses. Ved bruk av TCP overføring må avsender få bekreftelse på at pakken er kommet fram, pakkene mottas i riktig rekkefølge, og dette ville generert hakking i lyden. 18

19 Andre protokoller for over føring av lyd finnes, og nye er under utvikling. Vi er fornøyd med lydkvaliteten som framkommer i programmet, men det er selvfølgelig potensial for videreutvikling. Kommandoer Kommandoene i programmet er selvforklarende, men noen av kommandoene må ta hensyn til om en bruker av programmet ønsker å være anonym eller ikke. Add buddy Hvis en bruker ønsker å legge til en buddy kamerat, må kameraten godkjenne at han ønsker kontakt med brukeren. Hendelsesforløpet blir slik. Brukeren sender en beskjed til serveren om at han ønsker å legge til en kamerat. Serveren oppdaterer filen til kammeraten med kommandoen BWTAY (Buddy wants to add you). Dersom kammeraten ikke er online på dette tidspunktet skjer det ikke mer før kammeraten logger seg på. Dersom brukeren forsøker å adde kammeraten en gang til, før kammeraten har kommet online, vil brukeren få beskjed om at kammeraten allerede er addet. Hvis derimot kammeraten er online når han blir addet, eller at kammeraten logger seg på serveren og finner kommandoen BWTAY skjer følgende. Kameraten får opp dette spørsmålet: Svaret sendes til serveren, og dersom kammeraten svarte Yes!, vil kammeratens navn vises i GUI en. Serveren oppdaterer filene til både brukeren og kammeraten, og det sendes svar til brukeren om at kammeraten godtok å bli addet. Dersom kammeraten svarer No! slettes brukeren fra kammeratens fil. 19

20 CLIENT SERVER BUDDY AddBuddy(BuddyMailAddress) pakken ("ADDB" + BuddyMailAddress) sendes til serveren Server åpner Buddy's fil og sjekker om buddyen eksisterer. if (Buddy eksisterer && clienten ikke har prøvd å adde buddyen tidligere) { så legges clienten til med status BWTAY i fila. } if( Buddy online) { sendes kommandoen (AB + clientsobject) med en gang. } else if(! Buddy online) { sendes kommandoen (AB + clientsobject) neste gang han logger på. } Buddy mottar kommandoen AB fra serveren, og får forespørsel om han vil adde clienten. Serveren mottar answer og endrer statusen i buddyens fil. if(ok) { legger til buddy i sin egen fil. oppdaterer buddy vektor på serveren. } Buddyen sender da tilbake answer "OK eller DEL" Del buddy Kommandoen Del buddy, sender en beskjed til serveren om hvilken buddy som skal slettes, og fjerner buddiens nick fra brukerens GUI. Innholdet av pakken ser slik ut: DEL +buddys mail address. Serveren sletter brukerenens mail adresse fra kammeratens fil, og kammeratens mail adresse fra brukerens fil. Dersom kammeraten som slettes er online, fjernes brukerens nick fra kammeratens GUI. Hvis kammeraten ikke er online, vil ikke brukeren vises som buddy ved neste pålogging. 20

21 CLIENT SERVER BUDDY delbuddy(buddymailaddress) pakken ("DEL " + BuddyMailAddress) sendes til serveren Server åpner Buddy's fil, sletter clienten fra filen. Serveren åpner deretter clienten's fil og sletter buddyen fra filen hans. if( Buddy online) { sendes en notify til buddy } else if(! Buddy online) { vil clienten ikke vises i buddy sin GUI neste gang brukeren logger på } Clienten slettes fra brukerens GUI. Problemer vedrørende lyden. Når vi startet på lyddelen støtte vi på en del problemer. Dette var nytt for alle deltakerne, og en del søking etter informasjon gikk med. Vi fant mange eksempler på nettet, men de fleste var meget intrikat skrevet. Vi fant ut at det var mye bedre å skrive våre egne klasser, enn å begynne å omskrive disse. Det gikk med en del timer på dette og vi klarte å oppnå en meget bra lydkvalitet. Da vi skulle begynne å implementer klassene i programmet støtte vi på problemer. Det som skjedde var at vi ikke kunne opprette lydformatene da de skulle brukes. Vi fikk en del feilmeldinger om at det ikke kunne tildeles linjer fra og til lydkortet, og feilsøking måtte til. Den eneste måten vi har funnet ut som løser dette, er å opprette lydformatet for avspilling og opptak med en gang programmet startes. Dette vil medføre en feilmelding til brukere som ikke har lydkort installert. Det programmet gjør da, er å sette et flagg som bestemmer når og hvordan de skal brukes slik at ressurser spares. Hvis det er mulig å forandre dette senere, vil det være mer logisk å opprette disse forekomstene når de trengs, slik at man kan sjekke at maskinvaren er skikkelig installert. Da kan man disable ting i programmet, som da ikke kan brukes. 21

22 Her opprettes objektet for å sende lydpakker. Her opprettes objektet for å motta lydpakker. Ved å gjøre dette med en gang programmet startet, unngikk vi en del problemer. Ved å starte begge objektene i main(hoved funksjonen) så kunne vi stoppe og starte de som vi selv ønsket, slik at funksjonaliteten ble noen lunde det samme som den opprinnelige tankegangen var. Full og halv duplex Eldre lydkort støtter som regel bare halv duplex, noe som vil si at det kan ikke spilles av lyd samtidlig som det taes opp. Det vil igjen si at sanntids samtaler med slike kort blir vanskelig. Ved bruk av lydkort som støtter full duplex så kan samtaler over nettet realiseres. Lyd i full duplex vil si at lyd som kommer inn til lydkortet kan spilles av samtidlig som lydkortet tar opp. Lydkvalitet og forsinkelse Lydfrekvensen er låst til og samplings nivå er satt til 8bit. Buffer størrelsen er satt til 1024 bytes. Den minste nettverksbelastningen er da 8 * = 88.2kbit/s. Forsinkelsen i lyden er avhengig av frekvensen og bufferstørrelsen. Forsinkelsen øker med avstanden lyden blir sendt, men på et lokalnettverk har den ikke oversteget 250ms. 22

23 Sikkerhet Overføring av data til serveren inneholder kommandoer, brukernavn, passord, objekter osv. Disse dataene må beskyttes, og valget vårt falt på SSL kryptering. Java tilbyr SSL ("Secure Sockets Layer"), socket. Det er da snakk om en vanlig socket, men det legges til ett lag med sikkerhet over den underliggende nettverks transport protokollen, som TCP. Denne sikkerheten inkluderer: - Integritets sikkerhet. SSL beskytter mot modifikasjon av beskjeder av en aktiv linje tapping. - Autentikasjon. SSL tilbyr peer autentikasjon. Servere er vanligvis autentisert, og klienter kan bli autentisert på forespørsel fra serveren. - Konfidensialitet (Privacy). SSL krypterer data som sendes mellom klient og server. Dette beskytter konfidensialiteten til dataene, slik at passive linje tappere ikke ser sensitive data som passord og lignende. Disse sikkerhets måter er spesifisert av en Cipher suite, som er en kombinasjon av krypterings algoritmer brukt av en gitt SSL forbindelse. Under forhandlingsprosessen, må server og klient bli enige om en Cipher suite som er tilgjengelig på begge endepunktene av koblingen. Hvis det ikke finnes en felles suite, kan ikke SSL oppkoblingen opprettes, og ingen data kan overføres. Cipher suiten som brukes opprettes gjennom en forhandlingsprosess kalt handshaking. Målet med denne prosessen er at man kan opprette en ny, eller gjenopprette en session, som kan beskytte mange tilkoblinger over tid. //OPPRETTELSE AV SSL SERVER SOCKET //SSLServerSoket blir vanligvis generert ved hjelp av en SSLServerSocketFactory sslsrvfact = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault(); // Creates a server socket with ssl, the socket listens for connections on the specified port. SSLssocket = (SSLServerSocket)sslSrvFact.createServerSocket(port); // Enable cipher suites. SSLssocket.setEnabledCipherSuites(SSLssocket.getSupportedCipherSuites()); while(true) { // Listen for connections. SSLsocket = (SSLSocket)SSLssocket.accept(); // Create input stream and ouput stream. br = new BufferedReader(new InputStreamReader(SSLsocket.getInputStream())); pw = new PrintWriter(SSLsocket.getOutputStream(), true); // Autoflush ois = new ObjectInputStream(SSLsocket.getInputStream()); 23

24 oos = new ObjectOutputStream(SSLsocket.getOutputStream()); } Serveren vil da vente på oppkoblinger fra klienter, disse klientene må opprette forbindelsen med en SSLSocket. //OPPRETTELSE AV SSLSOCKET //Create an SSLSocket sslfact = (SSLSocketFactory)SSLSocketFactory.getDefault(); client.setsocket((sslsocket)sslfact.createsocket(client.getserverip(), client.getserverport())); client.getsocket().setenabledciphersuites(client.getsocket().getsupportedciphersuites()); //Create a buffered input stream to recive data from the server client.setbufferedreader(new BufferedReader( new InputStreamReader( client.getsocket().getinputstream()))); //create a buffered output stream to send data to server, (autoflush) client.setprintwriter(new PrintWriter(client.getSocket().getOutputStream(), true)); //create an objectoutputstream client.setobjectwriter(new ObjectOutputStream(client.getSocket().getOutputStream())); //create an objectinputstream client.setobjectreader(new ObjectInputStream(client.getSocket().getInputStream())); Det hadde selvfølgelig vært morsomt å utviklet krypterings algoritmer og en autentikasjonsserver selv, men vi fant raskt ut at tiden som er avsatt til prosjektet ikke var tilstrekkelig til dette. Alle klassene vi brukte for å sikre dataene, finnes på sun sine hjemmesider, og vi finner ingen grunn til å utdype dette emnet noe mer. Det er likevel viktig å presisere at tale overføringen sendes usikret. 24

25 Testing av programmet. Mye av tiden i prosjektet har gått med til testing underveis. Dette må gjøres for å avdekke eventuelle feil som oppstår. Når ulike klasser skulle implementeres senere i programmet, ble det også laget egne test klasser for disse. Dette hjalp oss med å avdekke feil tidlig slik at problemene som da kunne oppstå senere kunne løses bedre. Server: Det er denne delen som det er blitt mest testet på. Det er den som tar for seg det viktigste i programmet og er også da den mest kritiske delen. Her er det fremdeles mye som kan gjøres bedre men det vil vi komme tilbake til senere i rapporten under videreutvikling. Vi har også foretatt en stress test av serveren med flere ulike klienter. Dette var for å se om serveren taklet dette. Serveren inneholder en vektor som inneholder alle påloggede klienter, og som er en delt faktor blant dem. Det vil si at alle klientene deler et felles minneområde på serveren som de har tilgang til samtidig. Vi opplevde ingen anomaliteter (oppdateringsfeil), men oppfordrer på det sterkeste at det ved videre utvikling av programmet innføres en mutex for aksess kontroll til det delte minneområde. Klient: Denne delen er det som brukerne ser og oppfatter. Testingen her har vært gjort sammen med server, for å sjekke at de ulike funksjonene i programmet fungerer som de skal. Vi har fått tilbakemeldinger fra de som har vært med og testet det, slik at en best mulig GUI har blitt laget. Klient delen inneholder to servere(lyd/tekst) som skal motta informasjon fra de andre brukerne. Som nevnt tidligere skal kommunikasjonen foregå mellom brukerne og ikke via hovedserveren. Ved å gjøre det på denne måten slipper serveren ekstra trafikk. Problemet med å gjøre det slik er at hver bruker av programmet må ha en unik ip. Man kan fint logge seg på serveren fra en privat ip, men man kan ikke kommunisere med andre brukere. Hvis man f. eks kobler seg til Internettet bak en adsl router må man ha litt greie på hvordan Internettet fungerer. Man kan fikse det hvis routern støtter portforwarding. Når vi testet lyd delen over Internettet brukte vi et program for å styre den innkommende og utgående hastigheten på nettet. Programmet som ble brukt heter bandwith manager. Med dette programmet kan man senke og øke båndbredden til de verdiene man selv ønsker. Lyd overføringen ble testet mellom bredbånds leverandøren Tiscali ADSL og Holmestrands nettet H-Nett. Når vi senket overføringen til 128kbps mellom brukerne så fungerte tale overføringen uten problemer. Man kan redusere dette enda mer ved å komprimere talen. Dette kommer vi tilbake til i kapitlet om videreutvikling. Konklusjon I henhold til problemstilling og de mål som var satt for oppgaven, føler vi at vi har kommet i mål. Når vi startet med oppgaven var vi veldig spente på om avsatt tid til de forskjellige områdene var tilstrekkelig. Valget med å bruke egne filer til hver av brukerne som opprettet konto på serveren i forhold til å bruke en database kortet ned tiden vi brukte på den delen av oppgaven. En database implementasjon ville nok gjort programmet mer lesevennlig. Bortsett fra database delen fungerer applikasjonen som den skal. Klienter kommuniserer med serveren, skriftlig kommunikasjon mellom klienter og tale kommunikasjon mellom klienter. 25