Integratie van mobiele positiebepaling in instant messaging protocols

Transcriptie

1 Integratie van mobiele positiebepaling in instant messaging protocols Dimitri Devos, _ _dddevos Promotoren: prof. Filip De Turck, prof. dr. ir. Bart Dhoedt Begeleiders: Olivier Van Laere, Stijn Van Looy Scriptie ingediend tot het behalen van de academische graad van Licentiaat in de Informatica optie Toegepaste Informatica Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Paul Lagasse Faculteit Ingenieurswetenschappen Academiejaar

2 Dankwoord Allereerst wil ik mijn promotors, prof. dr. ir. Filip De Turck, en prof. Dr. ir. Bart Dhoedt bedanken voor mij een interessant thesis onderwerp te bieden. Claude Debast en NXP wil ik eveneens bedanken voor mijn thesisonderwerp, want zonder hen was deze scriptie waarschijnlijk eveneens niet mogelijk geweest. Verder wil ik mijn begeleiders Olivier Van Laere en Stijn Van Looy bedanken voor de vele uren hulp tijdens het jaar en de feedback tijdens het schrijven van deze thesis. Hun inzet heeft mijn thesis zeker beïnvloed in de goede richting. Mijn ouders wil ik ook bedanken dat ze mij de mogelijkheid gaven deze opleiding te volgen, en voor hun steun en aanmoediging door de jaren heen. Verder wil ik vooral mijn vriendin Jente Vandeburrie en beste vriend Donald De Spiegelaere bedanken om mijn thesis na te lezen en te verbeteren, alsook algemeen voor een positieve noot te zijn in een druk jaar. Ook Tom De Spiegelare wil ik speciaal bedanken om mee te helpen aan de opmaak van dit document. Ik wil al mijn vrienden zowel in Brugge als in Gent, die ik niet allemaal kan opnoemen hier, bedanken voor de leuke tijden en ontspanning. Dimitri Devos, juni II -

3 Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Dimitri Devos, juni III -

4 Overzicht Informatie Integratie van mobiele positiebepaling in instant messaging protocols Door Dimitri Devos Promotoren : prof. Filip De Turck, prof. dr. ir. Bart Dhoedt Begeleider: Olivier Van Laere Scriptie ingediend tot het behalen van de academische graad van Licentiaat in de Informatica optie Toegepaste Informatica Vakgroep informatietechnologie Voorzitter: prof. Dr.ir Paul Lagasse Faculteit Ingenieurswetenschappen Academiejaar Kernwoorden Instant Messaging, XMPP, architectuur, locatieservice - IV -

5 Samenvatting Deze thesis bespreekt het toevoegen van locatiegegevens aan een instant messenger protocol. Eerst werden bestaande werken die gerelateerd zijn aan dit onderwerp doorgenomen. De eigenschappen die het meest naar voor kwamen in deze werken zijn de architectuur die het best past voor de vereiste functionaliteit, alsook privacy bekommernissen over de locatiegegevens van elke gebruiker. Verder wordt GPS onder de loep genomen in hoofdstuk 2. De principes die de ruggengraat zijn van locatiebepaling worden kort aangehaald, zodat de lezer begrijpt hoe een GPS-ontvanger de locatie van een gebruiker kan bepalen. Het Jabber Instant Messenger (IM) netwerk werd gekozen om de locatieservice aan toe te voegen. Dit netwerk communiceert via het XMPP (Exensible Messaging and Presence Protocol). De verantwoording van deze keuze en hoe het XMPP protocol werkt kan gelezen worden in hoofdstuk 3. In hoofdstuk 4 wordt een architectuur voor het verdelen van de locatiegegevens voorgesteld. Hierbij worden de belangrijkste business processen alsook een korte opsomming van de volledige werking van deze service en de handelingen die kunnen uitgevoerd worden. Deze architectuur wordt geïmplementeerd in hoofdstuk 5. Er wordt meer uitleg gegeven over de werking van de cliënt, alsook de gebruikte server. Verder wordt ook de implementatie van de berichten weergegeven die gebruikt worden. In hoofdstuk 6 wordt het aanmaken van de kaart besproken daar een gebruiker zich niet veel kan voorstellen bij een getalvoorstelling van een locatie. Tenslotte wordt de architectuur getest aan de hand van grotere populaties, teneinde het gedrag van de locatieservice onder stress te bestuderen. We wensen te weten hoeveel berichten per seconde de locatieservice aankan op een bepaalde pc. Hierbij worden gedurende de test het aantal berichten per seconde, het aantal verloren berichten, het geheugengebruik en het cpuverbruik van deze pc gemeten. Aan de hand van de metingen worden bevindingen geformuleerd. Als afsluiting wordt nog een conclusie gegeven over het toevoegen van locatiegegevens aan een instant messaging protocol. V

6 Integration of location data in instant messaging protocols Dimitri Devos Supervisors: Filip De Turck, Bart Dhoedt, Olivier Van Laere, Stijn van Looy Abstract - Location tracking may be the next big step for instant messengers. However, distributing this data is not as simple as it may seem. Large amounts of users must be taken into account when an architecture for distributing location data is designed. Another key element is protecting this data from unauthorized users. In this paper an architecture is proposed for distributing location data, after which a series of performance tests are conducted on the architecture. Keywords: GPS, Instant messaging, IM, XMPP protocol, PubSub, User Location I. Introduction Global positioning is becoming more and more popular. Although today it is mostly being used to reach a destination in combination with road planners, it could be used for a lot more. Another way to use a GPS would be to reveal your location to the public, so people won t just be able to reach you at any time, they could also find you at any time, without having to trouble you about your whereabouts. This paper discusses the integration of location data in the XMPP instant messaging protocol, and proposes an architecture to distribute the location data. II. GPS GPS (Global Position System) currently uses 24 satellites that allows users anywhere on the planet to determine their geographic latitude, longitude and height. [4] A GPS-receiver picks up the signal that these satellites broadcast. This signal contains, amongst other information, details to let the receiver synchronise its clock with that of the satellite and the location and movements of the satellite. When the next signal is broadcast, the receiver can calculate its distance from the satellite, based on the time the signal took to reach the receiver. When the receiver knows its distance to four satellites, as well as the location of the satellites, it can calculate its own position. III. XMPP Definition & Origination XMPP [8] is an XML-based instant messaging protocol that uses a client-server oriented architecture. The idea originated from Jeremy Miller, who had to use four different instant messengers to keep contact with all his friends. He decided to build an Instant Messenger protocol that could serve as a standard and perform interoperability between other instant messaging networks. Advantages of XMPP XMPP has the ability to communicate with other instant messenger networks through bridges [6]. This feature, combined with the protocol s already large amount of users and open-source nature [1], makes it a good choice to work with. XEP-0080 XEP-0080 [2], an XMPP protocol extension, defines a way to extend the XMPP protocol with location data. Two things are discussed, the first being an extension in the XML-scheme to transport the data. The second is a suggestion on how the location data should be distributed. The general mechanism proposed is a publishsubscribe system, much alike the distribution of presence information. XEP-0060 [5] This is the XMPP extension ID for the publishsubscribe architecture mentioned in XEP A user who wants to publish data can create a pub-sub service on his IM-server, and other - VI -

7 users can subscribe to the location service. Once users are subscribed to the service, they receive the data when the publisher publishes new content. IV. Architecture Design When an architecture is designed, first the requirements should be examined. In the case of a location service, two main requirements are obvious, firstly the service needs to be able to handle a very large amount of users and messages [1], and secondly, the location of the users need to be kept private [7]. Business Processes Each of de business processes was analyzed, preconditions, post conditions and exceptions were formulated A Sequence Diagram was built for every business process, and a model was built for the entire process. The business processes that were distinguished are creating a location service, subscribing to a location service and the core business process: publishing to a location service. The locations service itself can be best described as a publish-subscribe service. Scalability & Persistence Scalability of the location services is solved in the same way scalability of the users is handled. The IM-server supports the location services. If the domain is of no importance, scalability can be achieved by using a new XMPP server with another domain name, and its own location services. When the domain does matter, a server farm architecture can be used. The location services will then also be handled by the farm. A server farm has the additional benefits that there is no single point of failure, and data can be stored redundantly. In terms of persistence, database software can be employed. Database software is usually scalable by design. This way, the IM servers only have to connect to this database to store and retrieve location information. V. Implementation For the implementation a new client was built. The client is capable of listening to COM ports and communicate location data to the location service on the IM-server. In order to be able to communicate the new type of message, the smack package [3] was also extended. Openfire was used as IM-server. This server supports the protocol extensions that are required. VI. Performance Tests To test the performance of the architecture, several tests were conducted in which clients publish location data via publish messages. The main performance function used is the amount of messages per second the server can handle. The results were compared to tests in which normal chat communication was used to distribute the location data to the same amount of users as each publish message had to reach. As closure, a conclusion is provided. References [1] M. Franklin, S. Zdonik (1997) A framework for scalable dissemination-based systems. ACM SIGPLAN Notices, Volume 32,Issue 10 (p94-105) [2] J. Hildebrand, P. Saint-Andre (2007). XEP- 0080: User Location. [3] IgniteRealtime.org. Smack API. ndex.jsp [4] E. D. Kaplan, C. Hegarty (2005).Understanding GPS: Principles and Applications. Artech House Inc (726p) [5] P. Millard, P. Saint-Andre, R. Meijer (2006). XEP-0060: Publish-Subscribe. [6]P. Saint-Andre, D. Smith (2005). XEP-0100: Gateway Interaction. [7] E. Snekkenes (2001). Concepts for Personal Location Privacy Policies. Proceedings of the 3rd ACM conference on Electronic Commerce (p48-57) VII

8 Inhoudsopgave 1 INLEIDING INTRODUCTIE TOT GPS VERSCHILLENDE GPS SYSTEMEN LOCATIEBEREKENING VIA GLOBAL POSITIONING SYSTEM Overzicht Triangulatie De afstand Timing Locatie van de satelliet INSTANT MESSAGING DEFINITIE DE KEUZE VAN NETWERK EN PROTOCOL VOOR DEZE THESIS JABBER INSTANT MESSENGER NETWERK HET XMPP-PROTOCOL Ontstaan van XMPP XMPP-archictectuur XMPP adressen XMPP berichten Presence berichten XMPP PROTOCOL EXTENSIES XEP-0080 : User location XEP-0060 : PUBLISH-SUBSCRIBE XEP-0163 : PERSONAL EVENTING VIA PUBSUB ARCHITECTUUR USE CASE DIAGRAM BUSINESS PROCES : EEN LOCATIESERVICE AANMAKEN OP EEN INSTANT MESSENGER PLATFORM Doelstelling Precondities Main success scenario Extensies Postcondities BUSINESS PROCES: INSCHRIJVEN OP DE LOCATIESERVICE VAN EEN ANDERE GEBRUIKER Doelstelling Precondities Main succes scenario Extensies Postcondities CORE BUSINESS PROCES : DISTRIBUEREN VAN LOCATIEGEGEVENS Doelstelling Precondities Main succes scenario Extensies Postcondities STATIC OBJECT MODEL Cliënt Server SCHAALBAARHEID PERSISTENTIE SAMENVATTING UITGEVOERDE ACTIES IMPLEMENTATIE CLIËNT KANT VIII -

9 5.1.1 Smack pakket aangepast Smack is een java pakket dat ontworpen is XMPP functionaliteit naar java te brengen. Een volledige beschrijving van smack is en wat smack kan, vind men in [15] Javax.comm Handleiding bij Messenger Werking Cliënt Genereren van de locatiegegevens SERVER KANT : OPENFIRE (VOORHEEN WILDFIRE) COMMUNICATIE : USE CASES Create location service Destroy location service Subscribe to service Unsubscribe to service Publish to service Discover services Request Subscriptions VISUALISATIE & GOOGLE MAPS GEGENEREERDE CODE VOOR DE KAART DE CODE STAAT OPEN VOOR VERBETERINGEN PERFORMANTIEONDERZOEK INTIALISATIE Doelstelling Beschrijving van het systeem Identificatie, selectie en definitie van interessante performantiematen PLANNING Definitie van de performantiefunctie Selectie van de vaste en variabele parameters Formuleren van verwachtingen OPZETTEN VAN HET EXPERIMENT Aanmaken van de populatie Build Run Clean EXPERIMENT UITVOEREN GradualPublish GradualChat FloodIncPublish RESULTATEN VERWERKEN Logs aanmaken : gradualpublish Logs aanmaken : gradualchat Logs aanmaken : floodincpublish Logs verwerken : gradualpublish Logs verwerken : gradualchat Logs verwerken : floodincpublish Gebruik van de excel gegevens Resultaten in grafieken CONCLUSIE Vorming van een gemiddelde van alle grafieken Totaalgrafieken, directe vergelijking Bevindingen CONCLUSIE & TOEKOMSTIG ONDERZOEK CONCLUSIES TOEKOMSTIG ONDERZOEK IX

10 Gebruikte afkortingen API: GPS: GUI: HTML: ID IM: JID: Mb: MHz: NMEA: Ram: UTC: XML: XMPP: Application Programming Interface Global Positioning System Graphical User Interface Hypertext Markup Language Identity Instant Messenger Jabber Identity Megabyte Megahertz National Marine Electronics Association Random Access Memory Universal Time Coordinated Extensible Markup Language Extensible Messaging and Presence Protocol - X -

11 Lijst van afbeeldingen FIGUUR 2.1: NAVSTAR SATELIET SYSTEEM [41]... 5 FIGUUR 2.2: HOEK TUSSEN SATELLIET BANEN EN HET EQUATORVLAK [42]... 5 FIGUUR 2.3 : SNIJDENDE SFEREN EN MOGELIJKE RESULTATEN [43]... 8 FIGUUR 3.1: NETWERKARCHITECTUUR GEBRUIKT BIJ HET XMPP-PROTOCOL FIGUUR 3.2: DE WERKING VAN STATUS BERICHTGEVING FIGUUR 3.3: LENGTE (LONGITUDE) EN BREEDTEGRADEN (LATITUDE) VOLGENS XEP-0080 [44] FIGUUR 4.1 : USE CASE DIAGRAM FIGUUR 4.2 : EEN LOCATIESERVICE AANMAKEN FIGUUR 4.3 : INSCHRIJVEN OP EEN LOCATIESERVICE FIGUUR 4.4 : DISTRIBUTIE VAN LOCATIEGEGEVENS FIGUUR 4.5: STATISCH OBJECT MODEL FIGUUR 4.6: AANMAKEN VAN DE LOCATIESERVICE OP DE IM-SERVER FIGUUR 4.7: GEBRUIKERS SCHRIJVEN ZICH IN OP DE LOCATIESERVICE FIGUUR 4.8: DE EIGENAAR PUBLICEERT LOCATIEGEGEVENS NAAR ZIJN LOCATIESERVICE FIGUUR 4.9: DE LOCATIESERVICE STUURT DE LOCATIEGEGEVENS VERDER NAAR DE INGESCHREVEN GEBRUIKERS FIGUUR 5.1: USER INTERFACE VAN DE CLIËNT FIGUUR 5.2: DE BT-338 VAN GLOBALSAT FIGUUR 5.3: OPENFIRE ARCHITECTUUR [45] FIGUUR 5.4: GEBRUIK VAN CONNECTION MANAGERS [46] FIGUUR 6.1: VOORBEELD VAN EEN WEERGEGEVEN KAART FIGUUR 7.1: TESTOPSTELLING Lijst van tabellen TABEL 3-1: DE LIJST VAN DE PRESENCE BERICHTEN DIE GEBRUIKT WORDEN IN HET XMPP PROTOCOL TABEL 3-2: DATAFORMAAT VOORGESTELD IN XEP-0080 VOOR LOCATIEGEGEVENS XI -

12 1 Inleiding De laatste jaren is het gebruik van positiebepaling en GPS (Global Positioning System) enorm toegenomen in onze maatschappij, met als voorbeeld bij uitstek de GPS-locatiebepalers in de wagen. Het primaire nut van de locatiebepaler of GPS-ontvanger is uiteraard dat dit toestel onze precieze locatie op de wereld kan bepalen. Een locatie op aarde wordt uniek bepaald door een longitude, een latitude en een hoogte. De GPS ontvanger is in staat deze locatie te berekenen aan de hand van een aantal berichten, die uitgezonden worden door Navstar GPS satellieten. Er bewegen momenteel 24 van deze satellieten in verschillende banen om de aarde, en dit op een zo n manier zodat een ontvanger berichten kan ontvangen van meerdere satellieten op elk moment en op elk punt op aarde. Door bepaalde tijdsopnames die toegevoegd zijn in het bericht, kan de ontvanger zijn afstand tot de satelliet die het bericht stuurde bepalen, en door andere informatie in het bericht weet de ontvanger ook waar de satelliet zich bevindt. Een kort overzicht over de werking van locatiebepaling aan de hand van berichten afkomstig van deze satellieten wordt gegeven in hoofdstuk 2. Eenmaal we op deze manier dus onze exacte locatie op aarde gevonden hebben kunnen we meerdere applicaties bedenken die deze informatie kunnen gebruiken. Een voorbeeld hiervan is de weg bepalen van onze huidige locatie naar een gewenste eindbestemming en dit via een wegennetwerk langs de snelste of kortste weg. Een andere manier om onze locatiegegevens te gebruiken, is bijvoorbeeld deze locatiegegevens beschikbaar stellen aan anderen, zodat zij weten waar jij je bevindt, zelfs wanneer je in beweging bent. Dankzij GPS-ontvangers kunnen we onze locatie te weten komen. Een mogelijke volgende stap in locatiebepaling is uiteraard het mededelen van deze locatiegegevens aan je vrienden, zodat ook zij weten waar jij je bevindt. In combinatie met persoonlijke GPS-ontvangers kan dit een belangrijke evolutie in communicatie en plaatsbepaling betekenen, want in principe kan iedereen op elk moment gelokaliseerd worden op deze manier. Ook kunnen bedrijven diensten aanbieden die je informatie aanbieden die relevant is met je positie, zoals de geschiedenis van een gebouw waar je voor staat, of ongevallen op de weg waarop je momenteel aan het rijden bent, waarbij ze een nieuwe route voorstellen of naar je 1

13 routeplanner sturen. In deze thesis wil ik dan ook dieper ingaan op het gebruik van persoonlijke GPS-ontvangers en vooral het verdelen van locatiegegevens. Voor de distributie van de locatiegegevens wordt een instant messenger protocol gebruikt, omdat de meeste gebruikers van een dergelijk systeem reeds een lijst van vrienden hebben in de vorm van een lijst van contactpersonen op een instant messenger netwerk, en vermoedelijk zijn net deze personen degene waaraan we onze locatie willen bekendmaken. In hoofdstuk 3 bekijken we een aantal van deze protocollen, en maken we uit deze lijst een keuze om mee verder te werken in de thesis. Hierbij bespreken we waarom we dit protocol kiezen en de architectuur ervan. Wanneer een architectuur voor de distributie van locatiegegevens ontworpen wordt, dient rekening gehouden te worden met verschillende vereisten en andere problemen. De voornaamste vereiste is dat de architectuur een groot aantal gebruikers moet kunnen ondersteunen. Bijgevolg is schaalbaarheid van de architectuur eveneens belangrijke factor. Ook willen we dat de service betrouwbaar is, zodat wanneer een component faalt de volledige service niet tot een halt komt. Een voorbeeld van een probleem dat verholpen moet worden is de vrije toegang tot de gegevens. De locatiegegevens van een gebruiker worden beschouwd als gevoelige gegevens, en deze mogen niet door onbevoegde gebruikers opgevraagd kunnen worden. De kern van de zaak is echter dat we ervan uitgaan dat een groot aantal gebruikers van de dienst willen gebruik maken. Dit resulteert in een grote hoeveelheid verkeer, iets dat ook zo goed mogelijk aan banden gelegd moet worden, zonder dat de locatiegegevens van de gebruikers verouderd raken. We beschouwen de locatiegegevens van een gebruiker als zijnde verouderd, wanneer de gebruiker teveel afstand genomen heeft van het punt dat bijgehouden wordt. Op dit moment moeten de locatiegegevens vernieuwd worden om een bepaalde nauwkeurigheid te garanderen. Er kunnen dus overwegingen gemaakt worden waarin het redelijk blijft de locatiegegevens van een gebruiker niet aan te passen, zoals bijvoorbeeld niet te updaten als de gebruiker niet beweegt. Het tweede belangrijke punt is dat over de tijd het aantal gebruikers significant kan stijgen. Het is dus wenselijk dat wanneer het aantal gebruikers lineair stijgt, we het aantal servers eveneens lineair kunnen uitbreiden en dat dit op een eenvoudige manier mogelijk is. De architectuur moet ook aangepast worden aan deze nood. 2

14 Extra opties zullen het systeem aanlokkelijker maken voor potentiële gebruikers. De mogelijkheid tot het instellen van de nauwkeurigheid van je locatie per gebruiker is zo n optie. Vanuit de invalshoek van de producenten van GPS-ontvangers is het verstandig rekening te houden met de heterogeniteit van de toestellen, en is de mogelijkheid tot inlezen van verschillende formaten en voorstellingen van locatiegegevens een groot pluspunt. Momenteel bestaan NMEA (National Marine Electronics Association) [34] en SIRF [35] om communicatie tussen de GPS-ontvanger en andere hardware te verzorgen. Ook andere bedrijven die diensten gebaseerd op locatiegegevens wensen aan te bieden moeten in staat kunnen zijn te communiceren in het formaat van hun keuze. Bij onderzoek naar voorgaande werken over het toevoegen van locatiegegevens aan communicatieprotocollen, vond ik onder meer [38]. Hierin wordt die een gelijkaardige locatieservice toevoegd aan het SIP (Session Initation Protocol) protocol. Hierbij worden vooral hoge eisen gesteld aan het privacy en security concept en het beheren van wie welke graad van toegang heeft tot de locatiegegevens van een gebruiker. Als architectuur wordt een cliënt-server architectuur voorgesteld waarbij de gebruiker zijn locatiegegevens doorstuurt naar de locatieservice, en de locatieservice deze informatie, eventueel minder nauwkeurig (vb tot nauwkeurigheid van de stad waarin de gebruiker zich bevindt in plaats van zijn exacte locatie) doorstuurt naar de vrienden van de gebruiker. Er wordt speciale aandacht geschonken aan een verschillende notificatie per gebruiker, waarbij elke gebruiker een bepaalde graad van vertrouwen kreeg, en de nauwkeurigheid van de ontvangen locatiegegevens hiervan een weerspiegeling is. In deze architectuur wordt geen rekening gehouden met grote hoeveelheden gebruikers of schaalbaarheid, wat net wel het punt is dat het meeste aandacht verdient gedurende deze thesis. Een ander voorbeeld is de GeoLocDesktopService [8]. Hierin wordt tevens een publishsubscribe architectuur voorgesteld, maar ook zonder opmerkingen in verband met schaalbaarheid en uitbreidbaarheid. Een derde voorbeeld is de AT&T Friends location service [11]. Voor een uitgebreide keuze aan opties en informatie over schaalbaarheid van gegevens distribueren, kunnen we [7] raadplegen. In dit werk wordt gewezen op drie karakteristieken die gekozen moeten worden wanneer een architectuur ontworpen wordt. Deze zijn push vs 3

15 pull, periodisch vs aperiodisch en unicast vs 1 naar N. Voorbeelden van 1 naar N communicatie zijn multicast of broadcast. Verdere informatie over publish-subscribe kan gevonden worden in [2],[6] en [26]. Om de privacy van de gebruiker te garanderen, en hier regels voor op te stellen, kunnen we terugvallen op [33]. Enkele protocollen hebben reeds voorzien in een aantal extensies om locatiegegevens voor te stellen en te distribueren tussen gebruikers. Een van deze protocollen is XMPP die voor het verdelen van locatiegegevens onder meer de extensie XEP-0080 gemaakt heeft, waarin ze niet alleen een dataformaat voor de locatiegegevens voorstellen, maar ook een manier om deze gegevens te distribueren. Meer hierover is te vinden in hoofdstuk 3. We ronden af met de ontworpen architectuur te testen op grotere populaties aan de hand van een simulatie. Details over het testen zijn terug te vinden in hoofdstuk 8, alsook de resultaten van de uitgevoerde simulaties. Aan de hand van de resultaten worden dan ook enkele bevindingen en gedachten vermeld. 4

16 2 Introductie tot GPS 2.1 Verschillende GPS systemen Wereldwijd zijn er vier positioneringsystemen, door verschillende continenten of landen gemaakt en elk met zijn eigen naam. We onderscheiden Het Amerikaanse Global Positioning System Het Europese Gallileo systeem Het Russische Glonass systeem Het Chinese BeiDou systeem Van deze vier nemen we voor de rest van de thesis enkel het Amerikaanse GPS ter beschouwing. Dit systeem bestaat voornamelijk uit 24 satellieten van NavStar. Deze satellieten cirkelen in 6 banen rond de aarde op ongeveer km hoogte en doen 12 uur over een volledige omwenteling. Deze banen zijn zo gevormd dat op elk punt op aarde op elk tijdstip altijd 4 satellieten bereikbaar zijn. De banen staan op een hoek van 55 met het equator vlak, waardoor ze zicht niet te vaak boven de poolregio s bevinden. Het is wel nog steeds mogelijk een goede locatie fix te krijgen in de poolgebieden. Voor meer informatie over het Navstar systeem, zie [22] en [23]. Figuur 2.1: Navstar sateliet systeem [41] Figuur 2.2: Hoek tussen satelliet banen en het equatorvlak [42] 5

17 2.2 Locatieberekening via Global Positioning System Overzicht Een poging om uit te vinden waar je bent is waarschijnlijk een van de mensheids oudste problemen. Navigatie en plaatsbepaling waren en zijn van cruciaal belang voor veel activiteiten maar nooit is het proces echt accuraat geweest. In de vroegste dagen gebruikte de mensheid de sterren om te navigeren. Ook oude instrumenten maakten gebruik van de sterren om een plaats te bepalen. Geen van de beschikbare technologieën waren voldoende, wanneer het Amerikaanse Ministerie van Defensie besloten had dat de militairen moesten beschikken over een precieze vorm van wereldwijde positiebepaling. Ze besloten daarom een eigen systeem op te bouwen, wat resulteerde in het Global Positioning System. Het Global Positioning System (GPS) is een wereldwijd radionavigatiesysteem dat gevormd is uit een constellatie van 24 satellieten en grondstations. GPS gebruikt deze door de mens gemaakte sterren als referentiepunten voor de berekening van posities nauwkeurig tot op enkele meters. Echter met meer geavanceerde vormen van GPS zijn metingen met een nauwkeurigheid van minder dan een centimeter zelfs mogelijk. We overlopen hoe GPS werkt in vijf logische stappen: De basis van GPS is triangulatie via satellieten. Om triangulatie uit te voeren bepaalt een GPS-ontvanger zijn afstand tot de satellieten dankzij de reissnelheid van radiosignalen. Voor het meten van de reistijd van het signaal van de satelliet naar de ontvanger, heeft de GPS-ontvanger een zeer nauwkeurige timing nodig, die via berekeningen bekomen kan worden. Samen met de afstand, moet je precies weten waar de satellieten zich bevinden in de ruimte. Hoge banen en zorgvuldige controle zijn de sleutel tot succes hiervoor. Vertragingen van het signaal veroorzaakt door bvb reizen door de atmosfeer moeten ingecalculeerd en verbeterd moeten worden. 6

18 Het idee achter een GPS is dus het gebruik van satellieten in de ruimte als referentiepunten voor de locatiebepaling op aarde. In de volgende punten gaan we dieper in op elk van de zonet beschreven stappen Triangulatie Onze positie wordt berekend op basis van metingen van onze afstand tot een aantal satellieten. Om onze exacte positie ondubbelzinnig te bepalen hebben we de afstand nodig van onze locatie tot vier satellieten. Drie satellieten zijn reeds genoeg als we onlogische antwoorden weglaten. Een vierde satelliet is wel voor een andere redenen vereist. Deze komt later in dit hoofdstuk aan bod De geometrie: Stel we meten onze afstand van een satelliet en vinden kilometer. Wetende dat we ons kilometer van een bepaalde satelliet bevinden, verminderen onze mogelijke locaties van overal in het universum tot het oppervlak van een sfeer met straal kilometer die gecentreerd is op deze satelliet. Vervolgens meten we onze afstand tot een tweede satelliet en constateren we dat we ons op kilometer van deze satelliet bevinden. We bevinden ons dus ook op een sfeer met een straal van kilometer rond de tweede satelliet. We bevinden ons dus niet alleen op de eerste sfeer, maar op beide sferen. Bijgevolg zitten we op een punt van de cirkelvormige doorsnede van deze twee sferen. Als we daarna een meting met een derde satelliet nemen en vinden dat we km van deze satelliet verwijderd zijn, verminderen de mogelijke locaties verder tot twee punten. Dit omdat de doorsnede van een sfeer met een cirkel gelijk is aan twee punten. (In ons geval, waarbij de centra niet gelijk zijn en er snijpunten aanwezig zijn). 7

19 Figuur 2.3 : Snijdende sferen en mogelijke resultaten [43] Dus door onze afstand te kennen tot 3 satellieten kunnen we onze mogelijke positie reduceren tot twee punten. Om te bepalen wat onze echte locatie is kunnen we een vierde satelliet gebruiken. Echter een van deze twee punten zal een onlogisch antwoord zijn (ofwel te ver van de aarde of verplaatsen met een onmogelijke snelheid), waardoor we deze kunnen afwijzen zonder meer. Een vierde meting is echter niettemin zeer handig om een andere reden. Meer uitleg hierover bij het synchroniseren tussen ontvanger en satelliet De afstand We zagen in dat de positie van een ontvanger berekend kan worden op basis van de afstand van ten minste drie satellieten tot de ontvanger. Maar hoe kan je de afstand tot iets wat rondzweeft in de ruimte bepalen? We doen dit door te meten hoe lang het duurt voor een signaal van de satelliet op de GPS-ontvanger ontvangen wordt. De afstand naar een satelliet wordt bepaald door te meten hoe lang een radio signaal onderweg is om ons te bereiken. Hierbij nemen we voorlopig aan dat de ontvanger en de satelliet perfect gesynchroniseerd zijn, en de ontvanger dus weet wanneer het bericht verzonden werd. 8

20 We veronderstellen dat de ontvanger op exact hetzelfde tijdstip dezelfde code genereert. Door het vergelijken van hoe laat pseudo-willekeurige code van de satelliet ontvangen wordt in vergelijking met de code van de ontvanger, kunnen we bepalen hoe lang het duurde voor het signaal om ons te bereiken. Vermenigvuldig de reistijd door de snelheid van het signaal en je hebt de afstand De wiskunde erachter: snelheid (120 kilometer/uur) x tijd (3 uur) = afstand (360 km) In het geval van GPS kunnen we de snelheid meten van een radiosignaal, dat in het vacuüm ongeveer kilometer per seconde is. Het probleem is het meten van de reistijd. Gaan we er eerst weer van uit dat de satelliet en de ontvanger op exact hetzelfde moment dezelfde code produceren. Wanneer de code van de satelliet ons bereikt, zijn de twee versies niet meer gesynchroniseerd. De versie afkomstig van de satelliet heeft een kleine vertraging opgelopen, omdat deze een afstand van km moest afleggen. Deze vertraging kan gemeten worden als een verschuiving in het produceren van de code en als we deze verschuiving bepalen, weten we hoe lang de code onderweg was. Nu we zowel de snelheid als de reistijd hebben, kennen we ook onze afstand tot de satelliet Pseudo-willekeurige code De Pseudo Random Code (PRC) is een fundamenteel onderdeel van GPS. Het signaal is zo ingewikkeld dat het bijna lijkt op willekeurige elektrische ruis. Vandaar de naam "pseudowillekeurig". Er zijn verscheidene goede redenen voor die complexiteit: in de eerste plaats helpt het complexe patroon ervoor zorgen dat de ontvanger niet per ongeluk synchroniseert met een andere signaal. De patronen zijn zo complex dat het zeer onwaarschijnlijk is dat een ander signaal dezelfde vorm zal hebben. Aangezien elke satelliet zijn eigen unieke pseudo-willekeurige code heeft kan de ontvanger tevens niet per ongeluk afstemmen op een ander satelliet signaal. Hierdoor kunnen alle satellieten gebruik maken van dezelfde frequentie zonder elkaar te storen. 9

21 We gingen er echter wel van uit dat de satelliet en de ontvanger op exact hetzelfde moment de pseudo-willekeurige code kunnen genereren. Ook dit ligt niet voor de hand. In het volgende punt zien we hoe we dit kunnen verwezenlijken Timing Nauwkeurige timing is de sleutel tot het meten van de afstand tot satellieten. Satellieten zijn juist omdat ze atoomklokken aan boord dragen. GPS-ontvangers hebben geen al te nauwkeurige klokken, omdat metingen naar een extra satelliet deze fouten kunnen verwijderen. Als het meten van de reistijd van een radiosignaal de sleutel is voor GPS, dan zullen de klokken zeer nauwkeurig moeten zijn. Stel dat hun timing een duizendste van een seconde fout is, dan resulteert dit in een fout van bijna 300 km. Bij de satelliet is de timing bijna perfect, daar elke GPS-satelliet een zeer nauwkeurige atoomklok aan boord heeft. Maar hoe zit het met de ontvangers op de grond? We hebben reeds gezien dat zowel de satelliet als de GPS-ontvanger de pseudo-willekeurige code zeer precies moeten kunnen synchroniseren. Indien de ontvangers eveneens atoomklokken nodig hadden, waarvan de kosten zeer hoog liggen, zou een gemiddeld persoon nooit een GPS-ontvanger kunnen betalen. Gelukkig hebben de ontwerpers van de GPS hiervoor een slimme oplossing bedacht die ons toelaat te synchroniseren met veel minder nauwkeurige klokken in onze ontvangers. Deze oplossing is een van de belangrijkste elementen van GPS en is eveneens een extra voordeel aan GPSontvangers: elke GPS-ontvanger heeft in principe dezelfde nauwkeurigheid als een atoomklok. Het geheim van de perfecte timing is om een de afstand te bepalen naar een vierde satelliet, en in plaats van drie perfecte metingen te maken, vier metingen met een kleine fout te maken. Indien de metingen perfect waren, sneden de metingen in één punt (onze huidige locatie). Maar bij imperfecte metingen zal de vierde meting niet door dit punt gaan. Hieruit kan de GPS-ontvanger concluderen dat hij niet perfect gesynchroniseerd is met de universele tijd. Gezien deze fout van belang is bij alle metingen, wordt de inwendige klok gecorrigeerd tot 10

22 alle metingen wel in één punt snijden. Zodoende is de GPS-ontvanger opnieuw gesynchroniseerd. Met de pseudo-willekeurige code als een zeer solide timing en synchronisatie signaal, en deze extra meting om ons perfect gesynchroniseerd te houden met de universele tijd is alles aanwezig voor meten van de afstand tot een satelliet in de ruimte. Maar voor de triangulatie nut kan hebben, moeten we ook precies weten waar de satellieten zijn Locatie van de satelliet Voor we satellieten kunnen gebruiken als verwijzingen moeten we weten precies waar ze zijn. GPS-satellieten bewegen in banen met zeer grote hoogte waardoor ze zeer voorspelbaar zijn Kleine variaties in hun banen worden gemeten door het Amerikaanse Ministerie van Defensie. De fout informatie wordt terug verzonden naar de satellieten Tot nu toe gingen we ervan uit dat we op elk moment weten waar de GPS-satellieten zijn, zodat we ze kunnen gebruiken als referentiepunten. Maar hoe kunnen we precies weten waar ze zijn wanneer ze km hoog bewegen? Deze hoogte is eigenlijk een voordeel in dit geval, want iets op die hoogte ligt ver genoeg buiten de atmosfeer. Dat betekent dat de baan weinig beïnvloed zal worden door de atmosfeer, waardoor ze makkelijk te berekenen valt. Daarenboven worden de satellieten vanaf de grond nauwkeurig geobserveerd door het Amerikaanse ministerie van defensie, want zelfs zo hoog verandert de baan van de satelliet, weliswaar zeer weinig. Dit door bijvoorbeeld de aantrekkingskracht van de maan, de of door de druk van zonnestraling op de satellieten. Deze afwijkingen worden naar de satelliet gestuurd waardoor de satelliet zijn locatie weer nauwkeuriger kent. Door al deze factoren in overweging te nemen is het systeem in staat een goede nauwkeurigheid te bieden aan elke GPS-gebruiker over de hele wereld. Voor meer informatie over de werking van GPS, zie [20],[21] 11

23 3 Instant Messaging 3.1 Definitie IM (Instant messaging) [37] omvat alle communicatietechnologieën waarbij tekstuele data ogenblikkelijk (real-time) wordt uitgewisseld. Instant messaging maakt gebruik van protocollen om te communiceren tussen eindpunten zoals software cliënts. Protocollen zijn omschrijvingen over hoe deze communicatie dient te verlopen. Een bepaalde cliënt kan meerdere protocollen ondersteunen, en omgekeerd kan een protocol gebruikt worden door vele cliënts. Er is dus geen bidirectionele relatie tussen protocol en cliënt. Talloze protocollen en cliënts zijn in gebruik en de strijd om dominantie gaat verder. Meer hierover is te lezen in [12] en [3]. Voorbeelden van protocollen zijn [36] Cspace DirectNet Gadu-Gadu Gale IRC MSNP Oscar Protocol PSYC Retroshare SIP/SIMPLE Skype protocol TOC2 protocol XMPP YMSG Zephyr Voorbeelden van multiprotocol cliënts zijn Adium Digsby Instantbird Kopete Meebo Miranda IM Pidgin Qnextt SIM Trillian Meca Messenger 12

24 3.2 De keuze van netwerk en protocol voor deze thesis Zoals uit voorgaande lijsten blijkt, bestaat er een grote diversiteit aan protocollen en cliënts. De belangrijkste IM-netwerken met gesloten protocollen zijn ICQ, MSN Messenger, Yahoo! Messenger en AIM. Al deze netwerken hebben een protocol en cliënt met dezelfde naam, behalve AIM die gebruik maakt van het OSCAR (Open Source Cluster Application Resources) protocol. Bij de netwerken met open protocollen vindt men IRC (Internet Relay Chat protocol) en Jabber (XMPP protocol) terug. Voor mijn thesis heb ik gekozen om met Jabber te werken. Dit netwerk heeft meerdere voordelen, waaronder het feit dat dit het open protocol netwerk is met het meeste gebruikers. Lijstje van IM-netwerken in volgorde van aantal gebruikers : Windows Live Messenger : 294 miljoen actieve gebruikers (11/2207) [27] Aim: 53 miljoen actieve gebruikers (09/2006), meer dan 100 miljoen in totaal (01/2006). Jabber: volgens Jabber, inc zijn er bijna 50 miljoen gebruikers [17]. Daar iedereen een eigen server kan opzetten en gebruiken, is het moeilijk dit aantal goed in te schatten. 3.3 Jabber Instant Messenger netwerk Jabber is een open instant messaging netwerk dat gebruik maakt van het XMPP protocol (Extensible Messaging and Presence Protocol [40]), een XML-gebaseerd protocol dat in oktober 2004 door de IETF (Internet Engineering Task Force) tot een standaard is uitgeroepen [30] [31]. Het XMPP protocol werd oorspronkelijk voor het Jabber netwerk ontworpen. Naast een van de netwerken met het meeste gebruikers te zijn heeft Jabber nog andere voordelen. Het belangrijkste voordeel van Jabber, is dat het XMPP protocol kan communiceren met andere protocollen en dus ook andere IM-netwerken. Deze communicatie wordt verzorgd door transports die op de XMPP server aanwezig zijn [28]. Op deze manier kan een gebruiker al zijn vrienden van verschillende IM-services samenbrengen onder een 13

25 enkele service. De voordelen van het gebruik van transports tegenover multi-protocol cliënts zijn Minder RAM geheugenverbruik voor de cliënt: pure Jabber cliënts moeten immers enkel via XMPP kunnen communiceren. Snellere ontwikkeling: pure Jabber cliënt ontwikkelaars moeten zich enkel bezighouden met Jabber en niet met de code of protocollen van andere IM-netwerken. Dit wordt verzorgd door de transport ontwikkelaars. Minder cliënt updates: als andere IM-netwerken hun protocol veranderen/uitbreiden dan moet iedere gebruiker de nieuwste cliënt installeren. Bij Jabber moeten enkel de transports op de server opnieuw geïnstalleerd worden wanneer het niet om een XMPP update gaat. In deze gevallen hoeft de gebruiker hier niet in tussen te komen. Jabber heeft ook een grote online community achter zich, die het XMPP protocol verder aanpassen en uitbreiden. Deze community communiceert via verschillende fora. Voorbeelden van dergelijke fora zijn te vinden in [14] en [16]. De goedgekeurde uitbreidingen worden gepubliceerd als XMPP protocol extensies, waarvan enkele speciale aandacht verdienen in deze thesis. De extensies die meer aandacht verdienen worden besproken in Het XMPP-protocol Ontstaan van XMPP Het idee achter de Jabber Instant Messaging en Presence technologie komt oorspronkelijk van J. Miller. Deze had het volgende probleem: hij moest 4 verschillende IM-cliënts gebruiken om met al zijn collega s te kunnen communiceren en kon hierbij enkel kiezen uit gesloten protocollen. Daarom besliste hij in 1998 om een open-source alternatief te bouwen, gebaseerd op XML, met als doel een Instant Messaging-standaard te ontwikkelen en de interoperabiliteit te bevorderen tussen de verschillende bestaande IM-systemen. Het project evolueerde snel en de eerste versie van Jabberd was een feit in mei Wie meer over de geschiedenis van XMPP wil te weten komen kan [39] bekijken XMPP-archictectuur Het XMPP-protocol volgt een cliënt-server architectuur. Een XMPP server of server cluster (server farm) bepaalt een domein. Gebruikers die een account hebben op dit domein hebben 14

26 een JID (Jabber ID) van de vorm van Wanneer twee cliënten binnen hetzelfde domein met elkaar willen communiceren, gebeurt dit via de server. Servers leggen ook verbinding met elkaar: op deze manier kunnen cliënten uit een verschillende domeinen ook met elkaar communiceren. Figuur 3.1: Netwerkarchitectuur gebruikt bij het XMPP-protocol XMPP adressen Zowel een XMPP-server, als een gebruiker die verbonden is door middel van een cliënt zijn adreseerbare entiteiten. Elke entiteit is identificeerbaar met een Jabber-ID of kortweg JID. Deze JID s zijn unieke sleutels die het adres vormen van elke entiteit. Een typisch JID voor een gebruiker heeft de vorm gebruikersnaam@domein/resource. Een XMPP-server JID bevat geen gebruikers-naam en wordt geïdentificeerd door zijn domeinnaam. Een gebruiker kan met meerdere clienten tegelijk online zijn. In dit geval wordt de resource gebruikt om zijn verschillende cliënts te onderscheiden. Vooraleer een gebruiker een adres heeft, moet de gebruiker dit aanvragen bij een domeinserver. Dit gebeurt door zichzelf te registreren op deze server. Doorgaans zal de server de volgende informatie verzoeken van de gebruiker : zijn gebruikersnaam en een paswoord waarmee de gebruiker later kan inloggen op de server. Afhankelijk van de server kan wel additionele informatie gevraagd worden. 15

27 3.4.4 XMPP berichten Voor de communicatie tussen twee entiteiten gebruikt XMPP een XML-stream. Langs deze stream worden XML-elementen verstuurd. Een XML-stream wordt geopend door de zender die een XML <stream> tag stuurt met de nodige attributen en namespace declaraties. Een dergelijk stream is unidirectioneel. Als de ontvanger wil antwoorden op de zender, dient deze zelf een XML-stream te initiëren. De stream wordt gesloten door een </stream> tag. Zolang de stream niet afgesloten is, kan de zender een onbeperkt aantal XML-elementen sturen naar de ontvanger. XMPP gebruikt drie types berichten die in de XML-stream geïdentificeerd worden door XML-stanzas. XML-stanzas zijn eerste niveau kind-elementen van de <stream> tag. Ze delen alle drie een set gemeenschappelijke attributen, namelijk to,from,id,type en xml:lang. De drie types stanzas zijn : 1. het standaard tekstbericht of message <message> 2. het statusbericht of presence <presence> 3. info/query berichten <iq> Message berichten Messages worden op dezelfde manier als verzonden, met een push-mechanisme. XMPP servers hebben overigens de functionaliteit dat wanneer een bericht niet verzonden kan worden naar een cliënt of andere server, de server dit bericht bewaart totdat de ontvanger terug online komt Presence berichten De kennis of iemand bijvoorbeeld beschikbaar is, bezet is (hieronder verstaan we wel aanwezig aan de pc, maar wordt liever niet gestoord, leest mogelijks niet onmiddellijk de berichten), of niet online kan van groot belang zijn wanneer een bericht binnen een bepaalde tijd de bedoelde ontvanger dient te bereiken. Wanneer we een bericht willen geven aan iemand in hetzelfde bureau hoeft deze informatie niet gecommuniceerd te worden, we zien het namelijk onmiddellijk wanneer we ons naar deze persoon richten. Wanneer iemand op een te grote afstand zit is het echter niet mogelijk te controleren of deze persoon ons bericht binnen een bepaalde tijd zal lezen. Hiervoor werden presence berichten 16

28 ontworpen. Deze vertellen ons wat de status van de ontvanger is. Hieruit kunnen we dan zelf een schatting maken hoe lang het kan duren alvorens de bestemmeling het bericht daadwerkelijk zal lezen. Het is bijvoorbeeld logisch dat dit het langst zal duren wanneer de bestemmeling offline is. Presence berichten worden voor twee belangrijke doeleinden gebruikt : Presence update: informeert contactpersonen van je huidige status Presence beheer: bestaat uit verzoeken en antwoorden en laat gebruikers toe zich in te schrijven op de presence update berichten van een andere gebruiker, alsook het controleren wie toegang heeft tot hun eigen status Tabel 3-1: De lijst van de presence berichten die gebruikt worden in het XMPP protocol Presence Protocol Type Commentaar Type available Update De gebruiker is beschikbaar om berichten te ontvangen unavailable Update De gebruiker is niet beschikbaar subscribe Beheer Aanvraag tot inschrijven op het roster van de ontvanger van verzoek dit bericht unsubscribe Beheer Aanvraag tot het uitschrijven uit het roster van de ontvanger verzoek van dit bericht subscribed Beheer Het inschrijven op het roster van de ontvanger werd antwoord geaccepteerd unsubscribed Beheer Het uitschrijven op het roster van de ontvanger werd antwoord geaccepteerd error Standaard Het standaard Jabber foutpakket voor presence problemen fout probe Server-server Zend alle presence informatie van de ene server naar de verzoek andere Niet iedereen heeft zomaar toegang tot onze presence informatie, wat ook een schending van onze privacy zou zijn. Presence berichten worden enkel gestuurd naar de gebruikers die deze volgens jou mogen ontvangen. Om deze reden worden gebruikers die ingeschreven zijn op jouw presence status bijgehouden op de XMPP server waarop je een account hebt. 17

29 Deze geïnteresseerde partijen worden bijgehouden in een lijst per gebruiker. Een dergelijke inschrijvingslijst heet een roster, en wordt ook als vriendenlijst omschreven. Het protocol is zo ontworpen om de verantwoordelijkheden van de gebruiker tot een minimum te houden, en de moeilijkere taken zoals berichten doorsturen en het onderhouden van de vriendenlijsten door de server te laten doen. De enige taken die de gebruiker moet uitvoeren zijn: zich inschrijven op het roster van andere gebruikers gebruikers die verzoeken zich op zijn eigen roster in te schrijven toelaten of weigeren veranderingen in zijn eigen presence melden aan de server. Bij zowel het beheer als updaten van presence is de instant messenger server de bemiddelaar tussen de maker van de presence informatie en de personen die deze ontvangen. Het presence update protocol gebruikt simpele eenrichtingsberichten. Een cliënt stuurt zijn status update bericht naar de server en de server stuurt dit verder naar elke gebruiker in het roster van de cliënt. Figuur 3.2: De werking van status berichtgeving Een presence bericht wordt net als elk ander bericht verzonden als een XML-stanza, en in het geval dat het bericht van het type presence is zijn er nog enkele kind elementen mogelijk te vinden binnen de presence stanza. We onderscheiden vier mogelijke kind elementen : 18

30 status : een willekeurige tekst die de status van de gebruiker beschrijft (bvb Aan de telefoon) prioriteit : een positieve numerieke voorstelling van de prioriteit van deze gebruiker. Gebruikers kunnen op meerdere plaatsen met dezelfde account ingelogd zijn, maar enkel de gebruiker met de hoogste prioriteit zal de boodschappen ontvangen error: het standaard Jabber error pakket show: kan gebruikt worden door gebruikers om bijvoorbeeld statusiconen weer te geven. Als dit veld niet geïndiceerd is, wordt aangenomen dat de gebruiker zich in de online of normale status bevindt. Enkele andere mogelijkheden voor dit veld zijn bvb chat of away Info/Query berichten Berichten die niet onder een van de vorige twee categorieën vallen, worden verstuurd als info/query berichten. Info/query houdt in dat een entiteit (een entiteit kan zowel een server als een cliënt zijn) via vraag en antwoord aanvragen kan sturen naar een andere entiteit. Afhankelijk van de waarde in het type attribuut zijn er enkele verschillende types info/query berichten te onderscheiden: Get: verzoek naar informatie Set: bepaalde waarden vervangen of instellen Result: het antwoord indien er geen fouten optraden Error: het antwoord indien er wel een fout optrad 3.5 XMPP Protocol extensies Om de locatieservice te implementeren (zie hoofdstuk 5) werd eerst gezocht naar bestaande oplossingen. Voor het XMPP protocol zijn een aantal extensies geschreven, om nieuwe concepten waaronder pubsub en meer dan honderd andere, te implementeren in het XMPP protocol. In elk van de extensies wordt de architectuur, communicatie en de syntax van de berichten die gebruikt worden in de respectievelijke extensie verduidelijkt. De extensies die van toepassing zijn voor het verspreiden van locatiegegevens zijn XEP-0060 Publish- Subscribe [24], XEP-0080 User Location[13] en XEP-0163, Personal Eventing via Pubsub[29]. 19

31 3.5.1 XEP-0080 : User location De extensie User Location [13] doet enerzijds een voorstel tot een gegevensformaat voor de locatiegegevens van een gebruiker te communiceren en op te slaan. Anderzijds worden twee architecturen voorgesteld die volgens de schrijvers van de extensie het meest geschikt zijn om deze locatiegegevens te communiceren naar andere gebruikers. Ik bespreek hierin de eigenschappen die specifiek van toepassing zijn voor de implementatie in de thesis. Voor een volledige beschrijving van de specificaties kunt u altijd de informatie online doornemen. Het voorgestelde dataformaat ziet er als volgt uit Tabel 3-2: Dataformaat voorgesteld in XEP-0080 voor locatiegegevens [13] De locatie-informatie bevinden zich tussen de XML-tags <geoloc> </geoloc>. Elk van de elementnamen uit tabel 4.1 is een mogelijk kind van de geoloc stanza. De locatiegegevens zelf wordt gegeven als XML-data in deze kindknopen, zoals bijvoorbeeld 20

32 <geoloc><lat>51,4534</lat><lon>2,9772</lon></geoloc> Verder wordt er ook gekozen om de eenheden voor lengte en breedtegraden in decimale graden voor te stellen, waarbij het zuiden en het westen negatieve getallen zullen voortbrengen, het noorden en het oosten positieve getallen. De eenheid voor de hoogte moet meters boven zeeniveau zijn, en de eenheid voor error is een boogminuut. Figuur 3.3: Lengte (longitude) en breedtegraden (latitude) volgens XEP-0080 [44] Voor de distributie van de locatiegegevens worden twee andere extensies aangehaald, namelijk Publish Subscribe en PEP (Personal Eventing via PubSub). Daar PEP een subset is uit Publish Subscribe kan algemeen gezegd worden dat de aangeraden transportatie van de locatiegevens via Publish Subscribe is. 3.6 XEP-0060 : Publish-Subscribe Deze XMPP protocol extensie beschrijft eerst en vooral een architectuur voor berichtgeving. Daarnaast beschrijft Publish-Subscribe ook in detail elke van de mogelijke berichtentypes die gestuurd kunnen worden door de cliënt, alsook de mogelijke antwoorden die de server kan geven. Dit zowel voor foutmeldingen die de server terugstuurt naar de cliënt, alsook meer uitleg over de fout. De volledige lijst valt buiten het bereik van deze thesis, maar de berichtentypes die van belang zijn voor de implementatie worden wel toegelicht, met een voorbeeld. Deze informatie is te vinden in het hoofdstuk 5.6, Communicatie : Use cases. 21

33 3.7 XEP-0163 : Personal Eventing via PubSub XEP-0163 [29] is een subset van XEP Deze extensie werd aangemaakt omdat de volledige specificaties van XEP-0060 als gecompliceerd beschouwd worden. Daarom bevat deze extensie voor vele opties van uit XEP-0060 een standaardkeuze, en wordt bepaalde functionaliteit automatisch uitgevoerd. Zo moet een gebruiker geen knoop aanmaken op de Openfire server : wanneer de gebruiker informatie publiceert, en de knoop is niet aangemaakt, dan wordt dit automatisch gedaan door Openfire zelf. Een ander voorbeeld van de doorgevoerde simplificaties kan uit de naam afgeleid worden. Het is duidelijk dat de service voor slechts één persoon dient, en bijgevolg is er slechts één publicerende entiteit, en kunnen moeilijkheden met meerdere publicerende accounts direct vermeden worden. Daar een gebruiker geen knoop aanmaakt kan er ook niet naar gepubliceerd worden, maar een aantal knopen worden standaard aangemaakt. Gebruikers kunnen dan in plaats van naar een knoop te publiceren naar een namespace publiceren. Voor de User Location extensie wordt gebruik gemaak van de namespace. Andere voorbeelden van namespaces zijn voor User Tunes (XEP-0118) en voor User Mood (XEP-0107). Een andere opmerking die hierbij zeker vermeld dient te worden, is dat er gebruik gemaakt wordt van een auto-subscribe systeem, gebaseerd op de presence lijst van de eigenaar van de PEP service. Dit wil zeggen dat elke persoon in de contactpersonenlijst van de eigenaar de gepubliceerde berichten zal ontvangen, zonder zich expliciet in te schrijven. Voor de implementatie van de eigen cliënt werd geen gebruik gemaakt van Personal Eventing via PubSub net omdat dit per definitie slechts een deel van de specificaties is. Voor meer informatie over de werking van het XMPP protocol en de bestaande extensies van het XMPP protocol, zie [1],[32],[40] 22

34 4 Architectuur Bij het ontwerpen van de architectuur dient ervoor gezorgd te worden dat deze schaalbaar is, en moeten we ook aandacht hebben voor de business processen die het vaakst zullen voorkomen. In het geval van locatiegegevens rondsturen zijn dit op de eerste plaats natuurlijk het distribueren van de locatiegegevens, het inschrijven op de locatieservice van een ander, en het aanmaken van een dergelijke locatieservice. Voor de persistentie is het handig om met bestaande databank oplossingen te werken. Er zijn voldoende schaalbare databankarchitecturen die, verbonden met de domeinserver, de locatiegegevens kunnen bewaren en oproepen wanneer nodig. Daar we locatiegegevens wensen toe te voegen aan een instant messenger protocol, hebben we reeds een instant messenger architectuur. Dit is een cliënt-server architectuur waarbij een of meerdere servers alle cliënts met elkaar in contact kunnen brengen. Elke cliënt legt hierbij contact met een server. Naarmate het aantal cliënts toeneemt, neemt ook het aantal servers toe dat nodig is om de cliënts te ondersteunen. Bijgevolg is het geen slechte keuze om de locatieservice van een bepaalde gebruiker actief te laten zijn op de server waar de gebruiker mee verbonden is. Op deze manier kunnen misschien wel minder gebruikers per server aanwezig zijn, maar groeit de globale locatieservice direct mee met het aantal gebruikers, daar het aantal servers eveneens genoodzaakt is aan te groeien. We maken dus de locatieservice een onderdeel van de instant messenger server waarmee de gebruiker verbinding maakt. Enerzijds worden de locatieberichten die gepublished worden door een gebruiker dan naar al zijn vrienden gestuurd langs dezelfde weg als een normaal bericht zou volgen om deze vriend te bereiken. Anderzijds kan een vriend op een andere server dan de locatiegegevens van een gebruiker opvragen door een verzoek naar zijn server te sturen, waarna deze server aan de server van de publisher diens locatie zal opvragen, en de vragende vriend het antwoord melden. In de volgende punten bekijken we eerst de vaakst voorkomende business processen meer in detail, waarna we een architectuur voorstellen aan de hand van de bevindingen in de detailweergave. Ik kies ervoor de business processen in chronologische volgorde te plaatsen in plaats van de meest frequent gebruikte bovenaan te plaatsen De gebruiker maakt dus eerst een 23

35 locatieservice aan, waarna vrienden zichzelf kunnen inschrijven op deze service. Daarna is het pas zinvol om locatiegegevens te sturen naar de locatieservice en ontvangen alle vertrouwelingen de locatiegegevens van de publisher. Een volledig overzicht van de use cases wordt gegeven in het volgende punt. 4.1 Use Case Diagram Figuur 4.1 : Use case diagram 4.2 Business Proces : Een locatieservice aanmaken op een instant messenger platform Doelstelling Wanneer een gebruiker zijn locatiegegevens wil publiceren aan vrienden, moet hij hiervoor eerst over een persoonlijke locatieservice beschikken, waarop zijn vrienden zich dan moeten inschrijven Precondities De gebruiker die wenst een locatieservice aan te maken dient eerst een account te hebben op het instant messenger platform in kwestie Main success scenario 1. De gebruiker logt in met zijn account 2. De gebruiker kiest om een locatieservice aan te maken 24

36 3. De creatie van de locatieservice wordt bevestigd aan de gebruiker, en medegedeeld aan de administrator ter informatie. 4. De gebruiker wordt op zijn eigen locatieservice ingeschreven Extensies 1a De gebruiker heeft geen account De gebruiker dient een account aan te maken op het desbetreffende instant messenger platform. 1b De gebruiker slaagt er niet in om in te loggen op zijn account De gebruiker wordt verzocht zijn login en paswoord te controleren, fouten aan te passen, en nogmaals te proberen. Indien dit meermaals faalt, kan verondersteld worden dat de instant messaging service tijdelijk onbeschikbaar is. 2a De aanvraag wordt geweigerd Dit gebeurt bijvoorbeeld omdat de gebruiker reeds een locatieservice heeft. 3a Een probleem is opgetreden bij het verwerken van de aanvraag of het aanmaken van de locatieservice. De gebruiker wordt op de hoogte gebracht van het mankement, met verontschuldigingen alsook de boodschap dat dit zo snel mogelijk verholpen wordt. De administrator wordt tevens op de hoogte gebracht van het probleem Postcondities De gebruiker beschikt over een locatieservice waarop andere gebruikers zich kunnen abonneren. 25

37 Figuur 4.2 : Een locatieservice aanmaken 4.3 Business Proces: Inschrijven op de locatieservice van een andere gebruiker Doelstelling De locatiegegevens van een andere gebruiker ontvang je niet zomaar. Je moet eerst kenbaar maken aan de service dat je interesse hebt in de locatiegegevens van een bepaalde gebruiker. Dit kan door je te abonneren op zijn locatieservice Precondities De gebruiker die zich wenst te abonneren heeft een account op het instant messenger platform en een cliënt die gebruik kan maken van deze locatieservices Main succes scenario 1. De gebruiker logt in met zijn account 2. De gebruiker stuurt een verzoek naar de locatieservice om zich erop te abonneren 3. De locatieservice stuurt het verzoek door naar de eigenaar van de service (de publisher) 4. De publisher laat de gebruiker toe op zijn locatieservice (bericht naar de locatieservice) 26

38 5. De publisher kent de aanvrager een graad van vertrouwen toe (bericht naar de locatieservice) 6. De locatieservice voegt de gebruiker toe aan de lijst van vertrouwelingen van de gebruiker, met de gepaste vertrouwensgraad. 7. De locatieservice informeert de aanvrager dat deze nu geabonneerd is, alsook de nauwkeurigheid van de informatie die hij ontvangt Extensies 1a De gebruiker heeft geen account De gebruiker dient een account aan te maken op het desbetreffende instant messenger platform. 1b De gebruiker slaagt er niet in om in te loggen op zijn account De gebruiker wordt verzocht zijn login en paswoord te controleren, fouten aan te passen, en nogmaals te proberen. Indien dit meermaals faalt, kan verondersteld worden dat de IM-service tijdelijk onbeschikbaar is. 2b De locatieservice ontvangt het verzoek niet De cliënt probeert een vast aantal keer het bericht te verzenden, en wanneer dit blijft falen, verwittigt hij de gebruiker dat de locatieservice niet gecontacteerd kan worden. 3a De publisher is niet online De locatieservice bewaart het verzoek bericht tot de publisher online komt. Ondertussen wordt de aanvrager wel medegedeeld dat zijn abonnering pending (in een wachttoestand) is. 3b De publisher is wel online, maar communicatie tussen de locatie service en de publisher faalt. De locatieservice probeert een vast aantal keer de publisher op de hoogte te brengen van het aanvraag verzoek. Wanneer dit blijft falen wordt de administrator op de hoogte gebracht. Wanneer deze exceptie echter voorkomt, zullen andere business processen zeer waarschijnlijk ook falen. 5a De publisher laat de aanvrager niet toe op de locatieservice 27

39 De locatieservice laat de aanvrager weten dat zijn aanvraag geweigerd is, en dit beëindigt de huidige use case. 7a De aanvrager is op het moment van de goedkeuring niet meer online De locatieservice bewaart het bericht dat dient naar de aanvrager gezonden te worden, en wacht tot deze online komt om het dan te sturen Postcondities De gebruiker ontvangt nu telkens de nieuwe locatiegegevens van de publisher zodra deze nieuwe gegevens beschikbaar stelt. Figuur 4.3 : Inschrijven op een locatieservice 4.4 Core Business Proces : distribueren van locatiegegevens Doelstelling Dit is het belangrijkste en veruit het meest gebruikte business proces. Een gebruiker die zijn eigen locatie kan bepalen en een locatieservice heeft op de instant messenger service, kan zijn 28

40 locatiegegevens kenbaar maken aan andere gebruikers die hij deze informatie toevertrouwt. Deze gebruiker heten we de publisher Precondities De publisher beschikt over een eigen locatieservice op het instant messenger platform. Tevens dient hij in staat te zijn om zijn eigen locatie te bepalen. Voor de volledige uitwerking van dit business proces dient er ook iemand ingeschreven te zijn op de locatieservice, maar daar de publisher automatisch zelf ingeschreven wordt op zijn eigen service vormt dit geen probleem Main succes scenario 1. De GPS-ontvanger bepaalt een locatiefix 2. De GPS-ontvanger stuurt de locatiegegevens door naar de IM-cliënt van de publisher 3. De IM-cliënt controleert of de nieuwe locatiegegevens voldoende afwijken van de vorige locatiegegevens 4. De IM-cliënt stuurt de locatiegegevens naar de locatieservice van de gebruiker 5. De locatieservice slaat deze locatiegegevens op. 6. De locatieservice haalt de lijst op van alle gebruikers die deze locatiegegevens dienen te ontvangen 7. De locatieservice controleert welke gebruikers uit de lijst online zijn 8. De locatieservice controleert welke vertrouwensgraad de vertrouweling heeft en past het bericht per vertrouweling eventueel aan. 9. De locatieservice stuurt de locatiegegevens van de publisher door over het IM-netwerk naar elke online gebruiker die de gegevens dient te ontvangen Extensies 1a De GPS-ontvanger kan geen locatiefix bepalen De gebruiker dient zichzelf of zijn ontvanger te verplaatsen naar een locatie waar de ontvanger betere ontvangst of zicht heeft, en wel een fix kan bepalen. 2a De GPS-ontvanger kan geen verbinding maken met de IM-cliënt De gebruiker dient alle configuraties aangaande de verbinding te controleren, en eventuele fouten verbeteren. 29

41 2b De IM-cliënt herkent het formaat van de locatiegegevens niet De gebruiker moet de ontwikkelaars van de IM-cliënt contacteren, en hen attent maken op het gebrek alsook hen eventueel van de nodige informatie voorzien. Dit kan bvb via een helpdesk zijn. Later dient de gebruiker dan zijn IM-cliënt te updaten. 3a De locatiegegevens wijken niet voldoende af van de vorige De IM-cliënt negeert de nieuwe locatiegegevens om het verkeer in te perken. 3aa De locatiegegevens wijken niet voldoende af van de vorige, en een bepaalde tijd is verstreken. De IM-cliënt stuurt de recentste locatiegegevens toch door naar de locatieservice om aan te tonen dat de gegevens nog steeds live zijn. 4a De IM-cliënt is niet in staat de locatiegegevens te sturen naar de locatieservice Wanneer dit voorkomt wordt de verloren update genegeerd, en worden de locatiegegevens van de gebruiker de volgende keer doorgestuurd ongeacht de afwijking van de vorige locatiegegevens. Indien het uploaden van de locatiegegevens constant blijft falen dient de gebruiker op de hoogte gebracht te worden dat er mogelijks een probleem is met zijn internet verbinding, zijn upload mogelijkheden, of de locatieservice. 5a Er treedt een fout op tijdens het opslaan van de locatiegegevens De gegevens kunnen foutief opgeslagen worden of niet opgeslagen worden. In het laatste geval is de fout niet zo erg als het slechts eenmaal voorkomt, daar de gebruiker zich niet zo veel verder van de vorige gegevens zal bevinden. Indien de gegevens foutief opgeslagen worden, zal de gebruiker op een arbitraire plaats weergegeven worden. Dit kan echter niet voorkomen wanneer transacties als atomair beschouwd worden, en waarbij na een fout een rollback optreedt In het geval dat de transactie geannuleerd wordt, komen we zo in hetzelfde scenario als waarbij gegevens niet opgeslagen worden. 6a De lijst van gebruikers die de locatiegegevens dienen te ontvangen wordt niet gevonden Er is een probleem met de locatieservice. Een administrator wordt hierover verwittigd. De service zal ophouden met werken, en moet mogelijks heropgestart worden. Indien het probleem niet opgelost is moet een administrator het probleem nader bekijken. 30

42 7a De lijst van gebruikers die online zijn kan niet worden gevonden Zie extensie 5a 9a Een gebruiker heeft de nieuwe locatiegegevens niet ontvangen De locatieservice poogt een vast aantal keer om de locatiegegevens door te sturen. Wanneer dit niet lukt, worden zowel de publisher, de ontvanger, als de administrator hiervan op de hoogte gebracht Postcondities Alle gebruikers die online zijn en inzage hebben in de locatiegegevens van de publicerende gebruiker hebben de nieuwe locatiegegevens ontvangen en weten waar de publisher zich bevind. Figuur 4.4 : Distributie van locatiegegevens 31

43 4.5 Static Object Model Wanneer we alle business processen combineren, komen we tot een globaal beeld over de klassen die nodig zullen zijn. Figuur 4.5: Statisch object model Cliënt Aan de cliënt zijde hebben we uiteraard allereerst een gebruikersinterface nodig waarin de gebruiker de bijkomende informatie die nodig is voor het publiek maken van zijn locatiegegevens kan plaatsen. Een voorbeeld hiervan is de poort waarop de verbinding met de GPS-ontvanger tot stand gebracht wordt. We willen ook dat de gebruiker te allen tijde een kaart kan opvragen met de locatie van zijn vrienden. Als we niet wensen dat de gegevens nog 32

44 moeten opgevraagd worden aan de vriend op het moment dat een gebruiker die locatiegegevens opvraagt, moeten diens locatiegegevens reeds aanwezig zijn bij de cliënt. De cliënt heeft dus een klasse nodige waarin deze locatiegegevens continu bewaard worden. Hiertoe definiëren we een klasse Vriend, die een representatie is van een contactpersoon van de gebruiker, en hierin wordt de meest recente locatie van deze vriend bewaard. Wanneer deze vriend nieuwe locatiegegevens publiceert, kunnen deze in de Vriend klasse bewaard worden, hetzij door overschrijven van de vorige gegevens, hetzij door deze aan een lijst toe te voegen, en zo een pad van de publisher s locaties te vormen. Voor elke vriend is een instantie van de Vriend klasse aanwezig en elke vriend is uniek door zijn JID. Alle vrienden van een gebruiker kunnen opgevraagd en gemanipuleerd worden via een klasse VriendenPool, die niets meer is dan een container voor alle vrienden van een gebruiker. Om de eigen locatiegegevens te weten te komen, moet meestal een verbinding gelegd met een GPSontvanger. De klasse LocatiegegevensCollector beheert deze verbinding. Wanneer het verzamelen van locatiegegevens begint, start deze klasse een aparte thread die luistert naar berichten die de GPS-ontvanger uitzendt, en stuurt deze verder naar de locatieservice van de gebruiker. Alle communicatie tussen de cliënt en de server gebeurt langs een communicatieklasse, in bovenstaande figuur CommunicatieModule genaamd Server De server moet de locatiegegevens die elke gebruiker publiceert opslaan. Hiervoor krijgt de server een speciale klasse LocatieService die gemaakt wordt voor elke gebruiker die een locatieservice aanmaakt en die uniek bepaald wordt door het JID van die gebruiker. De gebruiker bepaalt ook wie zijn locatiegegevens mag ontvangen, diens vrienden. Een vriend wordt door de gelijknamige klasse voorgesteld in de server, en wordt toegevoegd aan de locatieservice van een gebruiker op het moment dat de eigenaar van de locatieservice deze toestemming geeft. De belangrijkste attributen van een vriend zijn het JID van de vriend, en zijn vertrouwensgraad. Verder worden op een server alle locatieservices bewaard in een locatieservice-pool, van waaruit ze ook kunnen beheerd worden. Bij problemen kan de administrator via de Administrator Interface dan ook rechtstreeks aan alle locatieservices via deze pool. De communicatie gebeurt net zoals bij de cliënts langs een communicatieklasse. 33

45 4.6 Schaalbaarheid Schaalbaarheid van de instant messenger service kan op twee manier beschouwd worden. Enerzijds kan het aantal gebruikers vergroot worden door een nieuwe domeinnaam aan te maken met daarbij een nieuwe server. Communicatie tussen gebruikers in verschillende domeinen wordt dan verzorgd door communicatie tussen de domeinservers. Anderzijds kan de schaalbaarheid binnen een enkele domeinnaam beschouwd worden. Als het aantal gebruikers blijft groeien, en deze willen allen een account binnen eenzelfde domeinnaam, kan na verloop van tijd een enkele machine deze last niet langer aan. In dit geval zou een server farm een oplossing kunnen bieden. Hoe een server farm werkt, en hoe men een dergelijke farm aanmaakt, is te vinden in [5] Een server farm heeft als extra voordeel dat er geen enkelvoudig breekpunt is, wat de betrouwbaarheid van de instant messenger service natuurlijk ten goede komt. 4.7 Persistentie Om de locatiegegevens van elke gebruiker op te slaan maken we gebruik van een aparte databank. Deze databank is verbonden met de instant messenger server van de gebruiker. In geval van een server farm zal deze databank opgesplitst zijn over de verschillende servers, met redundantie in de gegevens, zodat ook hier geen enkelvoudig breekpunt aanwezig is. 4.8 Samenvatting uitgevoerde acties Figuur 4.6: Aanmaken van de locatieservice op de IM-server 34

46 maakt een publicatieservice aan voor zijn locatiegegevens. Deze service kan voorgesteld worden als een knoop binnen de domeinserver. Figuur 4.7: Gebruikers schrijven zich in op de locatieservice Andere gebruikers kunnen mits toestemming van zich inschrijven op deze locatieservice. In bovenstaande figuur zijn en geïnteresseerd in de locatiegegevens van Figuur 4.8: De eigenaar publiceert locatiegegevens naar zijn locatieservice publiceert nieuwe informatie naar zijn locatieservice. 35

47 Figuur 4.9: De locatieservice stuurt de locatiegegevens verder naar de ingeschreven gebruikers De locatieservice stuurt de nieuwe gegevens door naar alle gebruikers die ingeschreven zijn op de service. 36

48 5 Implementatie Voor de implementatie werd als programmeertaal Java verkozen. Zowel de server als cliënt zijn volledig in Java geschreven. Om de locatieservice te implementeren werd eerst gezocht naar bestaande oplossingen. Voor het XMPP protocol zijn een aantal extensies geschreven, om nieuwe concepten waaronder pubsub en meer dan honderd andere, te implementeren in het XMPP protocol. In elk van de extensies wordt de communicatie en de syntax van de berichten die gebruikt worden in de respectievelijke extensie verduidelijkt. De extensies die van toepassing zijn voor het verspreiden van locatiegegevens zijn XEP-0060 Publish-Subscribe[24], XEP-0080 User Location[13] en XEP-0163, Personal Eventing via Pubsub[29]. 5.1 Cliënt kant Smack pakket aangepast Smack is een java pakket dat ontworpen is XMPP functionaliteit naar java te brengen. Een volledige beschrijving van smack is en wat smack kan, vind men in [15] Toevoegen van functionaliteit : ugent.smack.pubsub Klasse GenericElement Het doel van deze klasse is elk mogelijk XML stanza te kunnen bouwen. De klasse bestaat uit 4 mogelijke delen: 1. Een String name : de naam van het element, dit is tevens het eerste woord in het xml stanza. Deze naam is noodzakelijk bij elk GenericElement. GenericElement element; Voorbeeld: element = new GenericElement( street ) Resultaat: <street/> of <street></street> 2. Een HashMap<String,String> met daarin de attributen die bij de naam van het xml element horen. Een GenericElement kan geen of meerdere attributen bevatten. Voorbeeld:. element.put( jid, cliënt@domein ) Resultaat: <street jid= cliënt@domein ></street> 37

49 Volgende twee elementen sluiten elkaar uit, een GenericElement kan slechts ofwel een content- ofwel een of meerdere kindelementen hebben. 3. Een String XMLContent : de inhoud van het element, dit is de hetgeen tussen het begin van de stanza en het einde van de stanza staat Voorbeeld: element.setxmlcontent(weidestraat) Resultaat: <street jid= client@domein >weidestraat</street> 4. Een ArrayList bestaande uit andere GenericElementen. De weergave van dit xml element wordt net als de XMLContent weergegeven tussen het begin en einde van de originele stanza. Dit kan recursief toegepast worden. Een GenericElement kan meerdere andere elementen hebben als kind. Voorbeeld: parent.setchild(element) Resultaat: <geoloc><street jid= cliënt@domein >weidestraat</street></geoloc> Er zijn twee constructoren van deze klasse : GenericElement(String naam); GenericElement(String node,string naam) De tweede klasse voegt automatisch het attribuut node, en het ingegeven node id toe aan het element. Deze constructor werd toegevoegd omdat dit attribuut zeer frequent voorkomt in de berichten. Voorbeeld: GenericElement element = new GenericElement( cliënt.geoloc, create ) Resultaat: <create node= cliënt.geoloc ></create> Klasse PubSubIQ : Deze klasse implementeert de interface IQ. De enige methode van deze interface die ingevuld moet worden is getchildelementxml. Deze methode wordt ingevuld met return "<pubsub xmlns=\""+getnamespace()+"\">"+getchild().toxml()+"</pubsub>"; de methode getchild geeft een GenericElement terug. In tegenstelling tot het GenericElement mag PubSubIQ slechts 1 GenericElement als kind hebben. Klasse PubSubMessage 38

50 Deze klasse is een extensie van de klasse Message. Van deze klasse dient de methode ToXML overschreven te worden, daar deze methode belangrijk is voor de communicatie. Net zoals PubSubIQ neemt de PubSubMessage een GenericElement als kind, en is dit kind uniek Aanpassen en uitbreiding aanwezige klassen Packetreader In de klasse PacketReader werden in de methode parseiq enkele regels toegevoegd zodat pakketten van het pubsub type correct geparsed zouden worden en in een PubSubIQ gegoten worden. Hiervoor wordt de nieuwe methode ParsePubSubIQ aangeroepen. Packetparserutils De tweede aanpassing vindt plaats in de klasse PacketParserUtils waar pakketten van het type Message geparsed worden. Ook daar is een methode parsepubsubmessage toegevoegd die een PubSubMessage teruggeeft. Zowel een PubSubIQ als een PubSubMessage kunnen verzonden worden, daar ze respectievelijk IQ en Message implementeren en uitbreiden, en zowel IQ als Message een implementatie zijn van Packet. GenericElement is hiervan geen extensie en kan bijgevolg niet op zichzelf verzonden worden Javax.comm De nodige bibliotheken om een verbinding te leggen naar de COM poorten van een computer zijn standaard niet aanwezig in de Java klassenbibliotheken. Het is dus noodzakelijk om deze bibliotheken te installeren als we de berichten willen kunnen lezen die de GPS-ontvanger stuurt langs deze COM poorten. Een dergelijke bibliotheek is het pakket javax.comm. Een gedetaileerde beschrijving van dit pakket is terug te vinden op [19], en de API kan bekeken worden op [18]. Het pakket bevat 3 bestanden, die in de juiste directories geplaatst moeten worden om een goede werking te garanderen. We beschouwen als basispad de map waarin de verschillende Java versies die geïnstalleerd zijn op de computer terug te vinden zijn. Standaard is deze map op een Windows besturingssysteem C:\program files\java. Kies de map met de Java versie die momenteel in gebruik is, normaal is dit een JRE versie. win32com.dll : dit bestand dient onder de map bin geplaatst te worden. comm.jar en javax.comm.properties : deze moeten onder de map lib geplaatst worden. 39

51 Wanneer deze files op de juiste plaats staan kan Java verbinding maken met de COM poorten en communiceren Handleiding bij Messenger Klassenlijst Main: start de Messenger klasse op, geen application logic in deze klasse Messenger: bevat voornamelijk de grafische interface van het programma GpsManager: verzorgt alle communicatie met Openfire server op gebied van pubsub GpsCollector: maakt een verbinding met de seriële poort COM4 en luistert naar locatiegegevens die uitgezonden worden GpsWindows: schrijft het bestand map.html, met daarin de locatiegegevens van vrienden PubSubListener: luistert naar pakketten die de server stuurt, om daaruit bestaande services te herkennen, alsook de subid s die de gebruiker heeft FriendPool: container klasse die alle vrienden bijhoudt. Bij elke vriend wordt een subid en een locatie bijgehouden Friend: representatie van een gebruiker Settings: deze klasse is niet actief in het programma, maar zou normaliter dienen om instellingen op te slaan bij de gebruiker Werking Cliënt Figuur 5.1: User Interface van de cliënt De implementatie is een proof of concept cliënt en is bijgevolg geen volwaardige cliënt. De cliënt kan geen accounts aanmaken op een Openfire server, noch vrienden toevoegen aan accounts. De populatie die bestaat uit twee gebruikers, moet gemaakt worden met andere software alvorens deze implementatie kan werken. Wanneer de populatie in orde is, kan men aan de hand van twee instanties van deze cliënt de locatie van beide gebruikers live zien op een kaart. Wanneer de cliënt opstart, dienen een aantal velden ingevuld te worden: Veld 1 : de domeinnaam van de server waarop de gebruikers een account hebben 40

52 Veld 2 : de account naam van de gebruikers Veld 3 : het paswoord van de gebruiker Veld 4 : de accountnaam van de vriend van de gebruiker Het spreekt voor zich dat bij de tweede instantie de velden 1 en 4 het omgekeerde zijn van velden 1 en 4 bij de eerste instantie. Wanneer alle velden juist ingevuld zijn, kan de knop init ingedrukt worden, waarna de cliënt verbinding maakt met de Openfire server en de account die teruggevonden wordt in veld 1 inlogt. Na de in te vullen velden vinden we de knoppen terug. De knop create maakt een pubsub service aan op de Openfire server met als node-id de accountnaam zonder het serverdomein achtervoegsel, gevolgd door de suffix.geoloc. Een accountnaam van de vorm cliënt1@domein maakt dan de pubsub service cliënt1.geoloc aan. Deze suffix is van groot belang, want wanneer een service discovery uitgevoerd wordt, zal deze implemenatie elke pubsub service die eindigt op deze suffix herkennen als een locatieservice, ook al is dit niet zo. De knop subscribe schrijft de ingelogde gebruiker in op de locatieservice van de vriend. Het al dan niet actief zijn van de knop en andere knoppen wordt verder in de tekst toegelicht. De knop unsubscribe heeft het omgekeerde effect als de knop subscribe, en wist de gebruiker uit de lijst van ingeschreven personen op de locatieservice van de vriend. De knop toggle collector de- en reactiveert de locatiegegevens-verzamelaar. Wanneer deze actief is worden de verzamelde gegevens ook onmiddellijk gepubliceerd naar de locatieservice als de account reeds ingelogd is. Telkens wanneer dit gebeurt ontvangen alle gebruikers die ingeschreven zijn op deze locatieservice nieuwe locatiegegevens over de gebruiker, en slaan deze op in het geheugen. Om de 3 seconden worden deze gegevens ook nog eens uitgeschreven naar het bestand die de html code bevat die weergegeven wordt wanneer de gebruiker op view klikt. De knop view is zeer eenvoudig en doet niets anders dan de gegevens die in de cliënt aanwezig zijn weer te geven via de standaard webbrowser van de gebruiker. Deze informatie is te lezen in het bestand map.htm. Wanneer geen locatiegegevens beschikbaar zijn en de 41

53 kaart wordt opgeroepen, wordt een kaart van de volledige wereld zonder markers teruggegeven. De knop discover vraagt aan de Openfire server welke services beschikbaar zijn. Afhankelijk van of de locatieservice van de vriend gevonden werd in het antwoord, wordt de knop subscribe actief gemaakt. De knop find zoekt naar de eigen subscripties. Afhankelijk van of een subscriptie gevonden wordt op de eigen locatieservice, wordt de knop destroy actief gemaakt en create gedeactiveerd. Ook wordt subscribe gedeactiveerd en unsubscribe actief gemaakt als een subscriptie gevonden wordt op de locatieservice van de vriend. Om dit te herkennen mag de naamgeving van de locatieservice niet veranderd worden. De knop Toggle Collector start en stopt de locatiegegevens-verzamelaar. Het starten of stoppen is afhankelijk van in welke staat de verzamelaar zich bevindt wanneer de knop ingedrukt wordt. De verzamelaar probeert standaard een verbinding te maken op de poort COM4 en leest daarna van de input van dit kanaal. De knop View opent de standaard browser op het besturingssysteem, en laadt de kaart met de locatiegegevens hierin Genereren van de locatiegegevens BT-338 Voor het aanmaken van de locatiegegevens werd eerst de BT-338 van Globalsat gebruikt [9]. Dit is een persoonlijke GPS-ontvanger met een bluetooth verbinding. Figuur 5.2: De BT-338 van Globalsat 42

54 Communicatie gebeurt door middel van het NMEA-protocol [34]. De GGA regels die uitgezonden worden bevatten de informatie waaruit de locatie van het toestel gelezen kan worden. Een voorbeeld van een dergelijke GGA-type regel is $GPGGA, , ,N, ,E,1,07,1.1,494.0,M,,,,0000* GPS-Gate Nadat bleek dat de locatiegegevens van de GPS-ontvanger correct ontvangen werden, werd gebruik gemaakt van GPS-Gate van Franson. Deze software genereert net als een echte GPSontvanger locatieberichten, en stuurt deze naar de COM poorten. De communicatie gebeurt ook door middel van het NMEA protocol. 5.2 Server kant : Openfire (voorheen Wildfire) Openfire is een Instant messaging server project van Ignite Realtime[] en maakt gebruik van het XMPP protocol. Openfire is volledig open-source en in Java geschreven, waardoor deze server mijn voorkeur genoot als implementatie server. Figuur 5.3: Openfire architectuur [45] 43

55 Een Openfire server heeft een eigen unieke domeinnaam, en alle cliënts die een account hebben op die server hebben een account in de vorm van Wanneer communicatie nodig is tussen cliënts in verschillende domeinen, kunnen twee domeinservers ook berichten onderling uitwisselen. Voor een enkele domeinnaam kan er maar één Openfire server instaan. Wel kunnen meerdere connection managers ingezet worden voor deze server, teneinde de werklast van de server te verlagen door bepaalde functies van de Openfire server over te nemen. Figuur 5.4: Gebruik van Connection Managers [46] Deze strategie is schaalbaar tot een bepaalde punt. Wanneer de populatie op de server groeit en de server de werklast van alle cliënts niet meer aankan, kan een connection manager in gebruik genomen worden die een deel van de werklast overneemt. Indien deze later ook niet meer volstaat kunnen er nog toegevoegd worden. Er is wel een grens aan het toevoegen van deze connection managers daar ze bepaalde functies van de Wildfire server nooit overnemen, en bij voldoende cliënts zal deze groep functies de Wildfire server nog steeds kunnen overbelasten. Testen hebben wel reeds uitgewezen dat een enkele Wildfire server in staat is meer dan gebruikers te onderhouden. Deze eindige uitbreiding is niettemin een minpunt. Indien meer gebruikers een account wensen, zijn ze genoodzaakt deze account op een andere server en dus ook een andere domeinnaam aan te maken. Een tweede minpunt van deze architectuur is dat er een 44

56 enkelvoudig breekpunt aanwezig is, als de Openfire server crasht, kunnen alle gebruikers op dit domein niet meer inloggen. Voor opslag kan Openfire een verbinding leggen naar een databank, en daarin de nodige informatie opslaan. Openfire 3.4.1, de versie gebruikt bij deze thesis, ondersteunt zowel XEP-0060, XEP-0080 als XEP Meer informatie over hoe Openfire omgaat met pubsub is te vinden in [4].Voor de implementatie werd de architectuur gebruikt die voorgesteld wordt in deze extensies. Deze architectuur sluit nauw aan bij de architectuur voorgesteld in hoofdstuk 4. Dit komt neer op een standaard Publish-Subscribe architectuur, waard de extra opties zoals het toepassen van een nauwkeurigheidsgraad per gebruiker niet werden geïmplementeerd. 5.3 Communicatie : Use cases Create location service Gebruiker stuurt <iq id="cliënt1.create" to="pubsub.griever-laptop" from="cliënt1@griever-laptop" type="set"> <pubsub xmlns=" <create node="cliënt1.geoloc"/> </pubsub> </iq> Openfire antwoordt <iq id="cliënt1.create" to="cliënt1@griever-laptop/smack" from="pubsub.griever-laptop" type="result"> </iq> 45

57 De terminologie node in dit bericht wijst op een knoop die gemaakt wordt in de openfire server. Elke service op een server wordt voorgesteld door een knoop. Elke knoop heeft een uniek id Destroy location service Gebruiker stuurt <iq id="cliënt1.delete" to="pubsub.griever-laptop" type="set"> <pubsub xmlns=" <delete node="cliënt1.geoloc"/> </pubsub> </iq> Openfire stuurt naar alle ingeschreven gebruikers <message xmlns=" id="cliënt1.geoloc b0ivh" from="pubsub.griever-laptop"> <event> <delete node="cliënt1.geoloc"/> </event> </message> Wanneer een node verwijderd wordt, worden alle ingeschreven gebruikers hiervan op de hoogte gebracht. Openfire antwoordt <iq id="cliënt1.delete" from="pubsub.griever-laptop" type="result"> </iq> 46

58 5.3.3 Subscribe to service Gebruiker stuurt <iq id="cliënt2.subscribe" to="pubsub.griever-laptop" type="set"> <pubsub xmlns=" <subscribe node="cliënt1.geoloc" </pubsub> </iq> Openfire antwoordt <iq id="cliënt2.subscribe" from="pubsub.griever-laptop" type="result"> <pubsub xmlns=" <subscription node="cliënt1.geoloc" subscription="subscribed" subid="xqn52e1o3181mrewc2ty1mcoe5ju7t41kr5000t2"> <subscribe-options/> </subscription> </pubsub> </iq> De node die aangemaakt werd had standaard subscribe profiel open. Bijgevolg moet geen toestemming aan de eigenaar van de locatieservice gevraagd worden, alle subscripties worden automatisch aanvaard. Wanneer dit bericht ontvangen wordt, wordt ook het subid bij de bijhorende inschrijving opgeslagen. 47

59 5.3.4 Unsubscribe to service De gebruiker stuurt <iq id="cliënt2.unsubscribe" to="pubsub.griever-laptop" type="set"> <pubsub xmlns=" <unsubscribe node="cliënt1.geoloc" subid="xqn52e1o3181mrewc2ty1mcoe5ju7t41kr5000t2"/> </pubsub> </iq> De Openfire server antwoordt <iq id="cliënt2.unsubscribe" from="pubsub.griever-laptop" type="result"> </iq> Publish to service De gebruiker stuurt <iq id="cliënt1.publish" to="pubsub.griever-laptop" type="set"> <pubsub xmlns=" <publish node="cliënt1.geoloc"> <item> <geoloc xml:lang="en" xmlns=" <lat> </lat> <lon> </lon> </geoloc> </item> </publish> </pubsub> </iq> 48

60 5.3.6 Discover services De gebruiker stuurt <iq to="pubsub.griever-laptop" id='nodes'> <query xmlns=" </iq> De Openfire server antwoordt <iq id="nodes" from="pubsub.griever-laptop" type="result"> <query xmlns=" <item jid="pubsub.griever-laptop" name="" node="cliënt2.geoloc"/> <item jid="pubsub.griever-laptop" name="" node="cliënt1.geoloc"/> </query> </iq> Request Subscriptions De gebruiker stuurt <iq id="g2ulm-10" to="pubsub.griever-laptop" type="get"> <pubsub xmlns=" 49

61 </iq> <subscriptions/> </pubsub> De Openfire server antwoordt <iq id="g2ulm-11" from="pubsub.griever-laptop" type="result"> <pubsub xmlns=" <subscriptions> <subscription node="cliënt1.geoloc" subscription="subscribed" affiliation="owner" subid="mok3sx1lg2btt5c7dukesoraebc3xk7a43hyx5yp"/> </subscriptions> </pubsub> </iq> 50

62 6 Visualisatie & Google maps Wanneer een gebruiker de locatiegegevens heeft van een van zijn vrienden, zal hij aan de hand van het land, de stad, de omgeving enz. informatie wel een idee hebben waar deze persoon zich bevind. Wanneer hij echter de exacte locatie van zijn vriend wil kennen, heeft de gebruiker niet veel baat bij zijn vriend s latitude en longitude te kennen. Een veel betere manier om de exacte locatie van zijn vriend duidelijk te maken, is door deze weer te geven als een punt op de kaart. Zelfs wanneer iemand op een kaart wordt weergegeven, is het nog steeds niet altijd duidelijk waar deze persoon zich bevindt zonder een betere blik op de situatie. Om dit proces te vereenvoudigen, wordt de gebruiker zelf ook op de kaart geplaatst, waardoor hij de positie van zijn vriend kan zien relatief tegenover die van zichzelf. Dit brengt met zich mee dat wanneer personen zich ver uiteen bevinden, een andere schaal van de kaart zal moeten gebruikt worden, willen we de grootte van de weergave van de kaart niet veranderen. Dit wordt dan ook uitgevoerd in de implementatie. Voor de visualisatie van de implementatie wordt gebruik gemaakt van Google Maps. Deze keuze wordt gerechtvaardigd het vrije gebruik van de service, zolang een gebruiker minder dan verzoeken per dag stuurt en een goede API [10]. De tweede vereiste beperkt de gebruiker tot een ververs ratio van maal per dag, of eens om de 1,73 seconden, een meer dan redelijke beperking. In de implementatie wordt een ververs ratio gebruikt van 5 seconden, wat nog steeds een behoorlijk live beeld geeft, en ruimschoots binnen deze beperking ligt. Hiermee wordt ook een tweede gewenste eigenschap aangekaart, de locatiegegevens van vrienden niet te laten verouderen. We wensen binnen een redelijke tijd (enkele seconden) te zien of onze vrienden in beweging zijn, en waar ze naartoe bewegen. 51

63 6.1 Gegenereerde code voor de kaart We illustreren dit onderwerp allereerst met een voorbeeld van een dergelijke visualisatie. We zien hierop twee gebruikers die zich in Brugge en in Gent bevinden. Figuur 6.1: Voorbeeld van een weergegeven kaart Wanneer we de code bekijken die deze visualisatie verwezenlijkt, zien we volgende regels 1. <meta http-equiv="refresh" content="5"> 2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"" 3. <html xmlns=" 4. <head> 5. <meta http-equiv="content-type" content="text/html; charset=utf-8"/> 6. <title>location of Friends</title> 7. <script src=" E0QC5Nc3p5tEFO5qiTKzhQhreIPIdeMpZebYB2Uf9W_0tOLYhSmTh2ZkDGTtKqa5DV2dejWuh0pg"type="text/javascript"></script> 8. <script type="text/javascript"> 9. function load() { 10. if (GBrowserIsCompatible()) { 11. var map = new GMap2(document.getElementById("map")); 52

64 12. map.setcenter(new GLatLng( , ), 6); 13. var point = new GLatLng( , ); 14. var marker0 = new GMarker(point); 15. map.addoverlay(marker0); 16. GEvent.addListener(marker0, 'click', function() {marker0.openinfowindowhtml("cliënt1@griever-laptop");}); 17. var point = new GLatLng( , ); 18. var marker1 = new GMarker(point); 19. map.addoverlay(marker1); 20. GEvent.addListener(marker1, 'click', function() {marker1.openinfowindowhtml("cliënt2@griever-laptop");}); 21. }} 22. </script> 23. </head> 24. <body onload="load()" onunload="gunload()"> 25. <div id="map" style="width: 1230px; height: 580px"></div></body></html> De meeste inhoud hiervan is standaard HTML code. We merken in het bijzonder regel 1 bovenaan op, die op een ververs ratio van 5 seconden wijst. Onderaan zien we in regel 25 dat de kaart 1230 pixels breed en 580 pixels groot is. Dit formaat werd aangepast aan de resolutie van het toestel dat de kaart opvroeg teneinde een passende kaart op het scherm te brengen. Voor de inhoud van de kaart zien we dat enkele regels meermaals voorkomen, en deze regels zorgen dan ook voor de markers op de kaart. Één marker wordt gemaakt door volgende regels code var point = new GLatLng( , ); var marker0 = new GMarker(point); map.addoverlay(marker0); GEvent.addListener(marker0, 'click', function() {marker0.openinfowindowhtml("cliënt1@griever-laptop );}); Als we dit analyseren, zien we dat er eerst en vooral een punt gekozen wordt op de kaart. Vervolgens wordt een marker gemaakt voor dit punt, en wordt deze marker op de kaart geplaatst. Tenslotte wordt aan deze marker een luisteraar gekoppeld. Deze luisteraar heeft als 53

65 functie de naam van de marker op het scherm te plaatsen, in dit geval de accountnaam van de gebruiker die aanwezig is op dit punt. Voor elke gebruiker wiens locatiegegevens beschikbaar zijn zal een set van deze regels terug te vinden zijn op de kaart. De laatste regel met informatie over de kaart is regel 12. Twee zaken worden verwezenlijkt in deze regel. Vooreerst wordt het middenpunt van de kaart bepaald. Voor het goede overzicht op alle gebruikers, wordt dit middenpunt berekend als het middenpunt tussen de twee verst uiteen liggende x coördinaten en de twee verst uiteen liggende y coördinaten, of in formulevorm (Xcenter,Ycenter)=((max(X1,X2, )+min(x1,x2, ))/2,(max(Y1,Y2, )+min(y1,y2, ))/2) Waarbij Xcenter en Ycenter de coördinaten van het midden van de map zijn en X1,Y1, X2,Y2, de coördinatan de contactpersonen zijn. Het tweede getal in deze regel wijst op de zoomfactor, in ons voorbeeld is dit 6. Dit getal ligt tussen 1 en 15. Telkens de zoomfactor met 1 verhoogt, verviervoudigt de oppervlakte op de kaart die weergegeven wordt (de lengte verdubbelt en de breedte wordt verdubbeld). 6.2 De code staat open voor verbeteringen Deze code illustreert dat de locatiegegevens accuraat kunnen weergegeven worden op kaarten, alsook een kleine extra qua functionaliteit zoals de popup vensters met de accountnaam erin. Dit is echter maar een basis ter demonstratie en er is zeker ruimte voor verbetering. Allereerst stel ik voor om de berekening van het centrum van de kaart aan te passen. Ik illustreer met een voorbeeld: neem twee personen, één ervan in Japan en de andere in Zuid-Amerika. Wanneer Google Maps deze personen weergeeft aan de hand van bovenstaande formule, wordt zowat de hele wereldkaart getoond, terwijl er een veel kortere afstand is, waarbij wel de -179,99 en 180 graden overbrugt moet worden. Hiermee kan rekening gehouden worden in een betere formule. Een ander voorbeeld voor verbetering is het verversen van de pagina anders aan te pakken. Op de manier waarop het nu gebeurt wordt de pagina herladen elke 5 seconden. Op deze 54

66 manier gaan de acties van de gebruiker telkens verloren na 5 seconden. Ik beschouw hierbij de kaart manueel verschuiven, inzoomen of de naam van een marker op de kaart bekijken. Ook het gebruik van een buitenstaande browser brengt enkele belemmeringen met zich mee. De pagina wordt weergegeven in de standaard webbrowser van de computer, omdat er op dit moment nog geen webbrowser in Java bestaat die Javascript binnen HTML kan verwerken. Het nadeel aan het gebruiken van een andere browser is dat we niet weten wanneer deze gesloten wordt, waardoor het bestand met de locatiegegevens te allen tijde moet bijgewerkt worden. Indien we beschikken over een Java webbrowser, weten we wanneer de gebruiker deze opent, en terug sluit. Bijgevolg moet het bestand enkel dan bijgewerkt worden, als we al een bestand nodig zouden hebben bij deze werkwijze. 55

67 7 Performantieonderzoek 7.1 Intialisatie Doelstelling De belangrijkste informatie die we na de testen willen hebben, is hoeveel publish-subscribe services een PC (Personal Computer) met bepaalde karakteristieken kan aanbieden aan een bepaalde populatie wanneer gebruik gemaakt wordt van de Openfire software. Vervolgens willen we ook weten of de deze service goed is geïmplementeerd of als deze tekort zou schieten wanneer we vergelijken met gelijkaardige communicatie die verzorgd werd met normale chat berichten. Zodoende wordt het aantal publish berichten per seconde vergeleken met het aantal normale chat berichten per seconde dat de Openfire server aankan op een bepaalde machine Beschrijving van het systeem Figuur 7.1: Testopstelling De performantieproeven worden uitgevoerd door twee computers. Op de eerste PC is een Openfire server actief, deze PC wordt verder de server-pc genoemd. De andere computer bevat een voor de performantietesten aangemaakt programma, dat vele cliënten inlogt, en elke cliënt pubsub berichten naar de server laat sturen. Deze tweede computer wordt vervolgens de cliënt-pc genoemd. De server-pc gebruikt tijdens de testen heeft een Pentium III 933mhz processor en 384 mb ram en de cliënt-pc is bevat een Pentium IV 1.5 ghz kern en 512 mb ram. Beide computers staan in verbinding met elkaar via 10/100 mbit netwerkkaarten, twee netwerkkabels en een router. Op beide PC s zijn geen andere processen actief buiten de standaard Windows processen en de processen die nodig zijn voor de performantietesten. Dit werd geverifieerd via Windows taakbeheer, waarbij onnodige processen beëindigd werden, en ongekende eerst gedetermineerd werden aan de hand van 56