IM4MHP: een XMPP Instant Messenger voor interactieve digitale televisie op het MHP-platform

Transcriptie

1

2 Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Onderzoeksgroep Wireless & Cable Directeur: Prof. Dr. Ir. L. Martens IM4MHP: een XMPP Instant Messenger voor interactieve digitale televisie op het MHP-platform door Kevin Hoekman Promotor: Prof. Dr. Ir. L. Martens Scriptiebegeleiders: Ir. T. Deryckere, Lic. M. Ide Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar

3 Dankwoord Allereerst wil ik mijn promotor, prof. dr. ir. Luc Martens, en ir. Tom Deryckere bedanken voor de kans om mijn thesis over dit boeiend onderwerp te maken. Ook wil ik in het bijzonder mijn begeleiders, ir. Tom Deryckere en lic. Michiel Ide, hartelijk bedanken. Eerst en vooral omdat zij altijd onmiddellijk met raad en daad voor mij klaar stonden en voor de vele uren dat ze mij vrijblijvend hebben geholpen. Ook voor de vrijheid die ze mij hebben gelaten, zowel bij de invulling van mijn onderwerp als bij mijn methodes van werken, en voor het vertrouwen waarvan ze hierbij blijk hebben gegeven. Tenslotte ben ik hen ook dankbaar dat ze ervoor gezorgd hebben dat mijn werk de nodige impact kreeg. Verder wil ik ook enkele collega s vermelden die een thesis deden rond hetzelfde onderwerp, voor het delen van hun kennis en ervaring, of voor het virtuele gezelschap. Dit betreft: Stijn Hennebel, David Plets, Toon De Pessemier, Kristof Demeyere en Pieter Deconinck. Stijn en David wil ik nog eens extra bedanken voor hun code ter mijn beschikking te stellen. Verder wil ik mijn twee beste vrienden Tim Pingnet en Jos Delbar bedanken voor hun advies, steun maar vooral gezelschap. Voor dezelfde reden wil ik ook de volgende mensen uit mijn jaar bedanken: Donny Tytgat, Jeroen De Wachter, Kris Couck, Jelle Nelis, Bas Boone, Jürgen Slowack en Bruno Quinart. Johan Wittebolle wil ik graag bedanken voor zijn behulpzaamheid. Een speciale plaats in dit dankwoord gaat uit naar mijn verloofde Veronique. Niet alleen voor mij al bijna 6 jaar graag te zien en er nog steeds dag na dag voor mij te zijn, maar ook om deze studies heel wat draaglijker te maken en te vullen met leuke herinneringen.

4 In verband met deze thesis wil ik haar bedanken voor de grondige verbeteringen, voor haar advies, en voor in de drukke periodes de huishoudelijke taken volledig op zich te nemen. Mijn toekomstige schoonouders hebben hier zeker een plaats verdiend voor hun steun en medeleven, maar vooral voor hun gastvrijheid. Carine wil ik nog eens extra bedanken voor al die jaren mijn was te hebben gedaan. Ook mijn toekomstige schoonfamilie wil ik bedanken voor hun attentie en gastvrijheid. Tenslotte wil ik mijn ouders bedanken omdat ze er altijd geweest zijn voor mij wanneer ik ze nodig had, hoe moeilijk dat soms ook was. Verder wil ik hen ook bedanken voor de toegewijde coaching, voor hun steun op alle vlakken en voor hun niet-aflatende geloof in mij. Kevin Hoekman, juni 2006

5 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. Kevin Hoekman, juni 2006

6 IM4MHP: een XMPP Instant Messenger voor interactieve digitale televisie op het MHP-platform door Kevin Hoekman Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar Promotor: Prof. Dr. Ir. L. Martens Scriptiebegeleiders: Ir. T. Deryckere, Lic. M. Ide Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Onderzoeksgroep Wireless & Cable Directeur: prof. dr. ir. L. Martens Samenvatting Deze thesis bespreekt in detail het doel, de gebruiks- en de implementatiemogelijkheden van Instant Messaging (IM) voor interactieve digitale televisie (idtv), met als uiteindelijk doel het ontwikkelen van een IM-systeem voor het Multimedia Home Platform (MHP). Hoofdstuk 1 presenteert IM als een killertoepassing voor idtv. De synergie tussen IM en tv gaat veel verder dan het ontstaan van enkele nieuwe functionaliteiten. Enerzijds biedt de inhoud getoond op het tv-scherm een meerwaarde aan IM. Anderzijds heeft IM het potentieel om van tv een hypersociaal medium te maken. Er zijn echter ook karakteristieken van tv die kunnen zorgen voor een verminderde gebruikservaring, wat een nefaste invloed kan hebben op het succes van de dienst. In hoofdstuk 2 wordt XMPP voorgesteld als meest geschikte kandidaat om IM te implementeren op idtv. De karakteristieken van XMPP sluiten namelijk bijzonder goed aan bij de vereisten. Bovendien blijkt in 2.4 dat er geen evenwaardige alternatieven zijn. IM-protocollen, en meer bepaald XMPP, hebben echter meer potentieel voor idtv dan enkel zuivere IM. Enerzijds is het via chatbots mogelijk om van het IM-netwerk gebruik te maken om op een flexibele manier nieuwe diensten aan te bieden. Anderzijds is XMPP geschikt als algemeen datatransportprotocol, en in het bijzonder voor het real-time uitwisselen van kleine hoeveelheden gestructureerde data. In hoofdstuk 4 wordt de ontwikkelde XMPP-client IM4MHP besproken. Bij het ontwikkelen ervan werd gebruik gemaakt van een aangepaste XMPP-library. IM4MHP biedt al de basisfunctionaliteiten van IM aan. Bovendien laat het toe om op een eenvoudige manier

7 nieuwe grafische userinterfaces toe te voegen, zodat het een ideale kandidaat is voor verder onderzoek naar gebruiksvriendelijkheid en social networking. Tenslotte worden in hoofdstuk 5 enkele interessante integratiemogelijkheden met andere toepassingen besproken. Trefwoorden Multimedia Home Platform (MHP), interactieve digitale televisie (idtv), Instant Messaging (IM), Extensible Messaging and Presence Protocol (XMPP), Jabber

8 itv and XMPP - a promising combination. Kevin Hoekman Supervisor(s): Prof. Dr. Ir. Luc Martens, Ir. Tom Deryckere and Lic. Michiel Ide Abstract Instant Messaging (IM) has the potential to become one of the killer applications of itv [1]. Several factors, however, make it hard to provide a good implementation of IM applications. Two examples are the high needs of scalability and the interoperability with existing IM services. This paper proposes to use the IETF standard XMPP (Extensible Messaging and Presence Protocol - also called Jabber) to implement IM, as it turns out to be very well adapted to the requirements on itv middleware platforms like the Multimedia Home Platform (MHP) [2]. Moreover, the use of XMPP doesn t limit itself to IM. The flexible architecture of XMPP enables a plethora of possibilities like easily adding new interactive services and creating a middleware for inter-application communication. Keywords Interactive Television, itv, Instant Messaging, IM, Multimedia Home Platform, MHP, Set-top Box, XMPP, Jabber. I. INTRODUCTION Since several years now, instant messaging (IM) has turned out to be an extremely popular service for computers and other devices. In spite of this, a lot of research still has to be done about its application to itv [1]. Although most of the concepts and functionality of traditional IM are reusable for itv, there are some core differences: the audience: itv targets a much broader audience: not all users are used to working with a computer, so the usual prerequisites cannot be expected. limited graphics and interaction: low resolution of TV display, distant viewing, simple remote control, problems with colours and narrow lines... limited resources on a set-top box: limited processing power, memory and storage space. New interesting IM functionalities can also appear when combining itv and IM. Two examples are given in [3]: displaying the program a user is watching together with his presence information and enabling users to send TV Program Recommendation (TVPR) to each other. Many different IM systems and protocols exist. We propose the use of the IETF standard XMPP (also called Jabber) to implement an IM system for itv. XMPP is a standardized IM protocol and makes use of XML to encode its packets. The base protocols are defined in the RFC 3920 [4] and 3921 [5]. II. XMPP PROTOCOL FOR IM IMPLEMENTATION A. Advantages of XMPP By choosing a client-server architecture, lightweight protocols and limited communication scenarios (clientserver and server-server), thin clients can be created. The more complex and resource-demanding issues fall under the responsibility of the server (presence and status management, packet routing, user account management, storing user or configuration information...). This makes XMPP an excellent candidate for implementation on limited resource environments like a set-top box. The client-server architecture has other benefits that we won t discuss in detail because they are not specific to itv: security and privacy, no firewall or NAT issues, centralized control over the domain (i.e. enforcing policies or ensuring QoS) and scalability. The core XMPP protocols support the main IM features: different types of messages: normal ( -like messages, one-on-one chat, group chat; exchanging presence information and managing subscriptions, contact lists and privacy lists (blocked users); channel encryption (TLS) and authentication (SASL); end-to-end signing and object encryption. It is however possible to add new extensions while staying compliant with the standard. Clients are free to invent their own protocols, protect them with custom XML namespaces, and still send them over generic XMPP networks ([6], p. 16). A list of existing extensions can be found at [7]. A side effect of using XMPP is that it is possible to interact with any device supporting an XMPP client (PC, mobile phone, PDA). Through a special serverside translation service called gateway, an XMPP client can also interact with other IM services (AIM, ICQ, MSN Messenger, Yahoo! Instant Messenger, ), as well as with other technologies (SMS, ,...). Another interesting feature of XMPP, called resources, enables users to simultaneously log in on the same account with different clients (and devices). Thanks to this, users that already have an account can reuse it without side-effects. Finally, by adhering to the XMPP protocols, we only have to implement an XMPP client, and use it to register on a normal XMPP server. Open-source XMPP client libraries are already available in java that need only little adaptation to be usable in an MHP environment (for

9 example [8]). Thanks to these existing tools, the IM client developer can concentrate on issues more specific to itv like interface design and usability. B. Disadvantages of XMPP There are some drawbacks associated with the use of XMPP. By using XML, the application is less bandwidth efficient, and the parsing can be quit resource demanding. Nevertheless we can use a XMPP dedicated parser that uses less resources. The fact that no direct communication is possible between clients could be a serious handicap for some applications, especially those exchanging a lot of data. There is however an extension (non-final at this time) available [9] which allows out-of-band data exchange. Another limitation is caused by the use of distributed servers and the fact that there is no standard way of specifying QoS requirements: in general (although it is possible to define new extensions that add these features), there are no QoS guarantees throughout the XMPP network. This means that there is no guarantee for the time of delivery, the order of delivered packets nor that the packet will arrive once and only once [6]. Finally, none of the extensions must be supported to be XMPP compliant. A client can thus not rely on support of a particular extension throughout the network. Extension support can be determined by Service Discovery [10]. The selection of extensions to add to a client has to be done carefully especially when having an implementation for MHP in mind, each extension making the client more resource consuming. III. ADDING SERVICES WITH CHATBOTS XMPP also enables developers to create new services for itv with minimal modifications to the client. This can be done by using automated chatbots. Chatbots are applications that autonomously behave like an IM user. A user can use messages to query or subscribe to a chatbot providing useful information. Some interesting services for itv that could be implemented using chatbots are: message translation, customer support, information services (time, weather, stock, horoscopes, news, yellow pages...) and message storage. in XML, and a proposed extension that defines a binding of SOAP to XMPP [13]. This way, the use of XMPP on the set-top box could provide a lightweight transport protocol for RPC or even SOAP. Examples of applications that could benefit from an XMPP middleware are: online and multiplayer games, T-commerce and educational applications. V. CONCLUSION We conclude that XMPP is well adapted to be used on limited device platforms such as a set-top box. That is why it is an excellent candidate for implementing an IM system for the MHP platform as demonstrated by the developed IM client IM4MHP. Its flexible and lightweight architecture and protocols also makes it suited for many other usages, like inter-application communication and RPC. People planning to use it should however be aware of its disadvantages. REFERENCES [1] C. Quico, Are communication services the killer applications for Interactive TV? or I left my wife because I am in love with the TV set., in Proceedings of the 1st European Conference on Interactive Television: from Viewers to Actors?, 2003, pp [2] European Telecommunications Standards Institute (ETSI), Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3, [3] J. Abreu, P. Almeida, and V. Branco, 2BeOn: Interactive television supporting interpersonal communication, in Proceedings of the sixth Eurographics workshop on Multimedia 2001, 2001, pp [4] P. Saint-Andre, Extensible Messaging and Presence Protocol (XMPP): Core, RFC 3920, [5] P. Saint-Andre, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, RFC 3921, [6] I. Shigeoka, Instant Messaging in Java: The Jabber Protocols, Manning Publications, [7] The Jabber Software Foundation (JSF), Jabber :: JEPs. http: // gelezen op 20/05/2006, [8] SMACK API, Smack API: Simple and Powerful Java client API for XMPP. org/smack/, gelezen op 20/05/2006, [9] T. Muldowney, M. Miller, and R. Eatmon, Jep-0096: File Transfer, [10] J. Hildebrand, P. Millard, R. Eatmon, and P. Saint-Andre, Jep- 0030: Service Discovery, [11] J. Karneges, Jep-0047: In-Band Bytestreams (IBB), [12] D.J. Adams, Jep-0009: Jabber-RPC, [13] F. Forno and P. Saint-Andre, Jep-0072: SOAP Over XMPP, IV. XMPP AS MIDDLEWARE XMPP can also be used for building distributed applications. This can be achieved by letting applications use the XMPP client as middleware, adding an extra layer of network abstraction. This enables applications to send data (textual, proprietary or serialized) and even procedure calls, through the XMPP network (see also [11]). In fact there exists a standardized extension [12] providing a method of encoding RPC requests and responses

10 Inhoudsopgave 1 Situering Digitale televisie Inleiding Het Multimedia Home Platform Instant Messaging Waarom een Instant Messenger voor interactieve televisie? Het verschil tussen de computer en idtv Verschillen in hardware Verschillen in scherm Verschil in publiek en perceptie De vereisten van een IM-applicatie voor idtv Functionele vereisten Kwaliteitsvereisten Implementatiekeuze XMPP/Jabber XMPP: werking De netwerkarchitectuur XMPP adressen i

11 Inhoudsopgave ii XML-streams XML-stanzas en de kernprotocollen van XMPP a de <message/> stanza: het berichtgevingsprotocol b de <presence/> stanza: het presence-protocol c de <iq/> stanza: het overige protocol Voordelen Voldoet aan de vereisten Lightweight clients Veiligheid en Privacy Een open internet standaard gebaseerd op XML Extra functionele- en kwaliteitsattributen Quality of service and policy Uitbreidbaar Bestaande software Nadelen XML Rechtstreekse communicatie tussen clients Quality of service Maturiteit van het protocol en extensies XMPP versus andere technologieën Peer-to-peer (P2P) en JXTA SIP en SIMPLE RTP Gesloten protocollen De toekomst van XMPP

12 Inhoudsopgave iii 3 Andere toepassingsmogelijkheden van XMPP Flexibel diensten toevoegen door middel van chatbots Voordelen van chatbots Voorbeelden a Voorbeeld 1: Deelnemen aan een tv-kwis b Voorbeeld 2: Gebruikersondersteuning c Voorbeeld 3: Een tekst-gebaseerde -client d Voorbeeld 4: Informatie opvragen e Voorbeeld 5: Impulsaankopen Opmerkingen Beperkingen van chatbots Interapplicatie-communicatie XMPP als generisch datatransportprotocol XMPP voor RPC XMPP als transportprotocol voor SOAP Besluit Implementatiemogelijkheden a Een XMPP-library in de applicaties b Een XMPP-middleware c Plaats van de IM-client in de middleware IM4MHP: een XMPP-client voor het MHP platform De SMACK -library Verantwoording van de keuze Aanpassen van de library aan MHP Gebruik van de SMACK API

13 Inhoudsopgave iv XML-parsing Overzicht van IM4MHP Architectuur a De grafische laag b De logica-laag c De interactie tussen de grafische en de logica-laag Verloop van de uitvoeringsdraden Input van de gebruiker Implementatie van tv-specifieke functionaliteiten Externe code Mogelijke uitbreidingen De testopstelling Vervulling van de vereisten Problemen bij het implementeren voor MHP Verschil tussen IM4MHP en AmigoTV Besluit en toekomstperspectieven 86 Appendix A: Inhoud van de CD-ROM 88

14 Lijst van afkortingen AI AIM A.L.I.C.E. API ASCII CPU DOM DTMF DVB DVB-J EPG ETSI FIXML GSM GUI HAVi HD HTML HTTP IAX ICE idtv IETF Artificiële intelligentie AOL Instant Messenger Artificial Linguistic Internet Computer Entity Application program interface American Standard Code for Information Interchange Central processing unit Document Object Model Dual Tone Multi-Frequency Digital Video Broadcasting DVB-Java Electronic Program Guide European Telecommunications Standards Institute Financial Information Exchange Markup Language Global System for Mobile Communications Graphical user interface Home Audio Video Interoperability Hard disk of hard drive HyperText Markup Language Hypertext Transfer Protocol Inter-Asterisk exchange Interactive Connectivity Establishment Interactive Digital Television Internet Engineering Task Force v

15 Lijst van afkortingen vi IM IQ IRC IRT itv J2ME JEP JID JSF JXTA LGPL MHP MPEG MSN NAT NTSC OCAP OS PAL pc PDA PHP PINE QoS RAM RC RFC RMI RTP Instant messaging of instant messenger Info-query Internet Relay Chat Institut für Rundfunktechnik Interactive Television Java 2 Micro Edition Jabber Enhancement Proposal Jabber ID Jabber Software Foundation Juxtapose GNU Lesser General Public License Multimedia Home Platform Moving Picture Experts Group Microsoft Network Network address translation National Television System(s) Committee Open Cable Application Platform Operating system Phase-alternating line Personal computer Personal digital assistants PHP Hypertext Preprocessor of Personal Home Page Tools Program for Internet News & Quality of Service random access memory Return Channel Requests for Comment Remote Method Invocation Real-time Transport Protocol

16 Lijst van afkortingen vii SASL SAX SIMPLE SIP SMS SOAP STB STUN Tcl TCP TLS tv TVPR UDP VOD VOiP XHTML XML XMPP Simple Authentication and Security Layer Simple API for XML SIP for Instant Messaging and Presence Leveraging Extensions Session Initiation Protocol Short message service Simple Object Access Protocol Set-top box Simple Traversal of UDP over NATs Tool Command Language Transmission Control Protocol Transport Layer Security Televisie Tv-program recommendation User Datagram Protocol Video on demand Voice over IP Extensible HyperText Markup Language Extensible Markup Language Extensible Messaging and Presence Protocol

17 Lijst van figuren 1.1 Representatie van de MHP-softwarestack (Bron: Wikipedia) Illustratie van de reisweg van een XMPP bericht Reisweg van een XMPP bericht door de XML-streams naar een lokale (a) en niet-lokale gebruiker (b) Toestandsdiagramma van de inschrijving op een roster Communicatie met een client van een andere IM-dienst door middel van een transport: (a) als de transport zich op dezelfde server bevindt; (b) als de transport zich op een andere server bevindt Interactie tussen de deelnemers en de chatbot tijdens een tv-kwis Probleem om de verzendtijd van het antwoord te bepalen Uitwisseling van informatie bij het gebruik van een -chatbot Datatransport tussen twee applicaties door gebruik te maken van het XMPPprotocol XMPP-enabled applicaties door middel van libraries XMPP-enabled applicaties door middel van een middleware De IM-client als gebruiker van de middleware De IM-client als onderdeel van de middleware De verschillende lagen van IM4MHP viii

18 Lijst van figuren ix 4.2 De verschillende packages van de grafische laag De klasse WindowManager Een klasse-diagram van de windowprofiles Een voorbeeld van de startup windowprofile Opbouw van de minimized windowprofile Opbouw van de maximized windowprofile Een klasse-diagram van de Windows Een klasse-diagram van de hardwaremanagers Een voorstelling van de testopstelling

19 Lijst van tabellen 1.1 Vergelijking van de rekenkracht en het geheugen tussen een paar STB s en een modale pc Vergelijking van de functionaliteiten beschikbaar in XMPP en SIP/SIMPLE Aantal gebruikers van enkele populaire IM-diensten. Bron: [124] Enkele karakteristieken van XMPP-client libraries x

20 Hoofdstuk 1 Situering 1.1 Digitale televisie Inleiding Na de komst van de kleurentelevisie vormt de interactieve digitale televisie (idtv) een nieuwe mijlpaal in de geschiedenis van de televisie. Door de aanzienlijke investeringen die reeds gebeurd zijn is het succes van deze nieuwe technologie cruciaal voor de betrokken partijen. Het is dan ook spannend afwachten op de aanvaarding door het grote publiek. De prognose is alvast voorzichtig positief aangezien nu al veel gebruikers de stap hebben gezet van analoge naar interactieve digitale televisie. Nog geen maand na de lancering in 2005 had Telenet reeds abonnees [19] en verkocht het nog voor eind januari 2006 de ste digibox [49]. De concurrent Belgacom TV had eind klanten [20]. Toch mag er niet te vroeg victorie gekraaid worden want het enthousiasme is verdeeld, zo hebben KBC en Fortis geen plannen om te investeren, terwijl hun concurrent ING dan weer de intentie heeft om in het eerste kwartaal van 2006 met t-banking te beginnen. Voor de gebruiker heeft idtv, in ruil voor een niet-verwaarloosbare investering, drie grote voordelen: meer kanalen, betere beeld- en klankkwaliteit en extra toepassingen. Voorbeelden van zulke toepassingen zijn interactieve tv-uitzendingen, een elektronische tv-gids (EPG), films en programma s op aanvraag (Video On Demand of kortweg VOD), chatten, egovernment, t-banking, t-commerce, fotoservice, spelletjes, enzovoort. Vooral 1

21 Hoofdstuk 1. Situering 2 de zogenaamde killertoepassingen, waaronder Instant Messaging (IM), zullen bepalend zijn voor het toekomstige succes van idtv Het Multimedia Home Platform In Europa is het Multimedia Home Platform (MHP) gekozen als open standaard voor de ontwikkeling van idtv-applicaties. Het is dan ook de standaard waarvoor de Instant Messenger ontwikkeld is, om precies te zijn de versie ervan. Dankzij de MHP-specificaties [26] kunnen idtv toepassingen uitgevoerd worden onafhankelijk van de onderliggende, vendor-specifieke hardware en software. De uitvoeringsomgeving bestaat uit een Java Virtual Machine (JVM) en een verzameling gestandaardiseerde API s die toegang verlenen tot de diensten van de set-top box (STB). In appendix A van [68] wordt een overzicht gegeven van alle API s en hun beschrijving. Figuur 1.1: Representatie van de MHP-softwarestack (Bron: Wikipedia) Er bestaan twee soorten MHP toepassingen, DVB-HTML toepassingen enerzijds en DVB- J (DVB-Java) toepassingen anderzijds, ook Xlets genoemd. De ontwikkelde IM-applicatie is een DVB-J toepassing. Deze applicatie gebruikt slechts een beperkt deel van MHP: voornamelijk de API voor Xlet management, de DAVIC API voor resource management en de HAVI UI API voor het ontwerpen van de Grafische User Interface (GUI). Er wordt

22 Hoofdstuk 1. Situering 3 ook gebruik gemaakt van een terugkeerkanaal (Eng. Return Channel of kortweg RC) dat de verbinding met het internet verzorgt. Meer informatie over MHP kan gevonden worden op [125] of in de specificaties [26]. 1.2 Instant Messaging Instant Messaging, of kortweg IM en letterlijk vertaalbaar als onmiddellijke berichtgeving, omvat alle communicatietechnologieën over een netwerk waarbij de tekstuele data ogenblikkelijk (real-time) wordt uitgewisseld. Dit in contrast met waar de overdrachtssnelheid lang niet zo belangrijk is. De meest bekende toepassingen van IM zijn chat, chatrooms, real-time berichten en het feit dat men kan zien of andere gebruikers online zijn of niet. Met de term Instant Messaging wordt meestal verwezen naar de protocollen die gebruikt worden om het formaat en de volgorde van de berichten vast te leggen. Met Instant Messenger bedoelt men meestal de software die effectief gebruikt wordt om te communiceren. Dit betekent niet dat er een bijectieve relatie bestaat tussen de protocollen en de software. Zo ondersteunen sommige clients meerdere protocollen, zoals bijvoorbeeld GAIM [30]. Er bestaat een grote diversiteit aan protocollen en software. De belangrijkste IM-netwerken met gesloten protocollen zijn ICQ, MSN Messenger, Yahoo! Messenger en AIM. Bij de netwerken met open protocollen vindt men IRC (Internet Relay Chat), Jabber en Talk terug. Sinds zijn ontstaan in het begin van de jaren 70 (PLATO) heeft IM een lange weg afgelegd. Tegenwoordig is het met meer dan 300 miljoen regelmatige gebruikers één van de populairste netwerktoepassingen. IM wordt gebruikt voor zowel professionele als recreatieve doeleinden, zowel in bedrijven als thuis en zowel op het internet als op gesloten netwerken. Tegenwoordig is IM trouwens niet alleen beschikbaar meer op computer maar heeft het ook andere toestellen veroverd: gsm, tablet, pda en nu ook de tv.

23 Hoofdstuk 1. Situering Waarom een Instant Messenger voor interactieve televisie? Om de aanvaarding van idtv te verhogen en het publiek bewust te maken van de voordelen ervan is er nood aan zogenaamde killertoepassingen. IM is hier één van, niet alleen door de reeds bewezen populariteit in de computerwereld, maar ook door de overtuiging dat het een extra dimensie zal kunnen toevoegen aan het tv-gebeuren. De combinatie tussen IM en tv opent de deur tot een wereld vol nieuwe mogelijkheden, toepassingen en diensten. IM heeft het potentieel om van tv een veel rijker en socialer medium te maken. Enerzijds wordt IM krachtiger dankzij deze synergie, omdat het gekoppeld kan worden aan de content die op het scherm getoond wordt. Reeksen, sportevenementen en films kunnen dienen als gespreksonderwerp. Gezamenlijke interesses tussen mensen kunnen hierdoor gemakkelijker aan het licht komen en zo het communauteitsgevoel versterken. Anderzijds wordt de tv-ervaring veel intenser omdat vrienden samen virtueel naar tv-programma s kunnen kijken: ze kunnen hun ervaring, gevoelens en mening over de content real-time met elkaar delen. Het is ook mogelijk om aan de hand van IM nieuwe diensten te implementeren die gesynchroniseerd zijn met de inhoud van het tv-programma. Hierbij kan gedacht worden aan enquêtes, kwissen, etc. Dit onderwerp zal verder in detail besproken worden in paragraaf 3.1 en verdient de nodige aandacht omdat een hogere participatiegraad juist één van de grootste troeven is van interactieve televisie. Mensen willen niet meer beperkt zijn tot een rol als toeschouwer, maar willen deelnemen. Zoals Joel Silver in Variety Feb zei: What is important to remember here is that entertainment is not just about storytelling anymore. It s about building universes where people can express themselves. They want to dive in. Praktisch gezien zijn er drie interessante functionaliteiten die ontstaan uit de synergie tussen IM en tv. Een eerste functionaliteit, voorgesteld in [14], is om te tonen naar welk tv-programma een gebruiker aan het kijken is aan de contacten in zijn vriendenlijst. Dit kan de band tussen

24 Hoofdstuk 1. Situering 5 vrienden versterken omdat zo gezamenlijke interesses aan het licht komen. Het kan ook een aanmoediging zijn om een gesprek te starten; een persoon kan bv. opmerken dat een vriend naar hetzelfde programma kijkt en hem om zijn mening vragen. Uiteraard moet de gebruiker deze optie kunnen uitschakelen om privacy redenen. Een tweede functionaliteit, vermeld in [1], is het sturen van Program Recommendations, wat erop neerkomt dat een gebruiker een bepaald tv-programma kan aanraden aan één van zijn contacten. Uiteraard kan hij dit ook doen in een klassiek bericht, maar het voordeel van deze aparte methode is dat het gekoppeld kan worden aan een EPG. Zo kan bij de zender alle informatie over het programma (begintijd, eindtijd, naam, samenvatting...) automatisch opgezocht worden, en de ontvanger kan het programma gemakkelijk toevoegen aan de playlist van zijn EPG. De laatste functionaliteit is het koppelen van chatrooms aan een tv-programma waarin fans met elkaar kunnen chatten. Dit kan een uiterst belangrijke functionaliteit zijn omdat het een manier is om mensen met een gedeelde interesse te ontmoeten en nieuwe contacten te leggen, met andere woorden om aan social networking te doen. Het belang van social network wordt weerspiegeld door het succes van sites als match.com, myspace.com, flickr.com of last.fm, allemaal websites waar communiceren met nieuwe of bestaande kennissen centraal staat. Bovendien voorziet de gedeelde interesse een goed onderwerp om het ijs te breken. Deze functionaliteit kan uiteraard uitgebreid worden naar chatten met iemand uit de cast, de presentator, de director of producer... Dit kan meerdere doelstellingen hebben: het is mogelijk om deze dienst aan te bieden tegen betaling, om een meerwaarde te bieden, of het kan een manier zijn om reclame-inkomsten te verwerven (bv. door expliciete reclameboodschappen; door een acteur een product te laten vermelden; door ervoor te zorgen dat de mensen op het gewenste moment kijken). Ondanks het onderzoek dat reeds gebeurd is ([14], [1], [78]) is het moeilijk te voorspellen of het beeld van idtv als hypersociaal medium werkelijkheid zal worden. In vergelijking met de computer zijn er enkele beperkingen die roet in het eten kunnen gooien.

25 Hoofdstuk 1. Situering Het verschil tussen de computer en idtv Verschillen in hardware De kostprijs van de set-top boxes (STB), namelijk de elektronische toestellen die idtv mogelijk maken, kan een belemmering vormen voor de grootschalige acceptatie van idtv. Om deze prijs zoveel mogelijk te drukken zijn de STB s beperkt in hun prestaties, voornamelijk de rekenkracht, het geheugen en de opslagcapaciteit. Tabel 1.1 geeft daar een idee van. Uiteraard moet men hiermee rekening houden bij het bouwen van zware applicaties. Tabel 1.1: Vergelijking van de rekenkracht en het geheugen tussen een paar STB s en een modale pc. ADB Q.75 Telenet Digibox Telenet Digicorder STB (DB-AD101) (DC-AD1000) Modale pc CPU (MHz) RAM (MB) Flash (MB) HD (GB) Verschillen in scherm Ook de aard van het medium televisie brengt technische beperkingen met zich mee. Zo is men, wat de invoermogelijkheden betreft, gelimiteerd tot een afstandsbediening, terwijl men bij de computer beschikt over muis en klavier. Applicatieontwerpers moeten daarom extra aandacht besteden aan de navigatie. Alle toepassingen die het invoeren van tekst vereisen staan daarom voor een uitdaging. Het is echter mogelijk om een draadloos klavier aan te sluiten op de STB. Of de gebruiker bereid is hiervoor nog eens 50e extra te betalen blijft nog maar de vraag. Het feit dat alles wordt weergegeven op een tv-scherm en niet op een computerscherm veroorzaakt ook problemen. Een eerste verschil is de pixel aspect ratio: in tegenstelling tot een computerscherm, dat bestaat uit vierkante pixels, zijn de pixels van een tv-scherm langwerpig in de hoogte. Zoals een computerscherm kan een tv-scherm verschillende picture aspect ratio s hebben

26 Hoofdstuk 1. Situering 7 (de verhouding tussen de breedte en de hoogte, bv. 16:9 voor breedbeeldtelevisie). Het probleem stelt zich in het feit dat het beeld uitgerekt kan worden als het getoond wordt op een ander aspect ratio dan diegene waar het voor bedoeld was. Hierdoor komt de leesbaarheid van de tekst in het gedrang. Ook de methode die gebruikt wordt om de beelden te tonen is verschillend voor beide typen schermen. Om bandbreedte uit te sparen gebruikt een tv-scherm interlacing: van elk beeld worden afwisselend enkel de even en de oneven horizontale lijnen getoond, en dus niet het hele beeld zoals op een computerscherm. Dit zorgt voor verschillende soorten artefacten; dunne lijnen kunnen hier bijvoorbeeld onder lijden. Hiervoor zijn verschillende oplossingen mogelijk. Voor tekst kiest men best specifieke lettertypes. Het standaard lettertype Tiresias is bijzonder geschikt, terwijl de zogenaamde Serif lettertypes te vermijden zijn. Het is aan te raden om voor horizontale lijnen een breedte van minstens 4 pixels te kiezen. Ook anti-aliasing toepassen op beelden kan een oplossing bieden (bv. door een gaussiaanse vervagingsfilter van radius 0.3 te gebruiken). Een ander nefast gevolg van interlacing is een slechte weergave van sommige kleuren. Zo zijn scherpe randen tussen kleuren met een hoog contrast te vermijden en kiest men liever voor koele of niet gesatureerde kleuren. Applicatieontwerpers moeten trouwens specifiek aandacht besteden aan de kleuren, omdat deze niet waarheidsgetrouw worden weergegeven op een tv-scherm. Een computerscherm gebruikt namelijk de RGB-kleurenruimte, terwijl een tv-scherm de YUV-kleurenruimte gebruikt (of YIQ in het geval van NTSC en OCAP). Het probleem is dat de gamuts (verzameling van alle representeerbare kleuren) van beide kleurenruimtes niet overlappen: er zijn daardoor kleuren in de RGB-kleurenruimte die niet voorgesteld kunnen worden in de YUV-kleurenruimte. De lagere resolutie van tv-schermen zorgt ervoor dat grafische content voor de computer, zoals bv. webpagina s, niet geschikt is voor tv. Dit probleem maakt het ontwerpen van een browser voor idtv praktisch onmogelijk. Tenslotte, als we willen dat de volledige GUI verschijnt op het scherm moet we er ook rekening mee houden dat enkel de clean aperture getoond wordt en dat de randen van het beeld kunnen wegvallen. Het probleem is dat de veilige zone kan veranderen van

27 Hoofdstuk 1. Situering 8 toestel tot toestel Verschil in publiek en perceptie Er zijn nog een aantal factoren waarin toepassingen voor idtv verschillen van die voor de computer. Enerzijds is het publiek veel breder: er zullen mensen bij zijn die nog nooit een computer gebruikt hebben. Daardoor mogen ontwikkelaars niet uitgaan van de voorkennis die men van een gemiddelde computergebruiker mag verwachten. De afstand tussen het scherm en de gebruiker is ook veel groter (idealiter 6x de diagonaal van het scherm) dan bij computers (idealiter minstens 60cm). Daardoor moet de tekst ook veel groter zijn: 18 pts is het absolute minimum, maar er wordt aangeraden om 28 pts gebruiken. Niet alleen de omgang met de toepassingen is anders maar ook de verwachtingen die gebruikers van idtv hebben. Mensen zijn gewend om tv te beschouwen als een betrouwbaar en veilig medium en zullen daarom zeer intolerant staan tegenover crashes of disfunctionerende software. Daarom is het belangrijk dat applicaties voor idtv aan strenge kwaliteitseisen voldoen. Ook veiligheid is een belangrijk onderwerp omdat bedreigingen als virussen, wormen, trojaanse paarden e.d. heel schadelijk kunnen zijn voor het imago van idtv. Er wordt voor die reden veel aandacht aan besteed in MHP waardoor er strenge maatregelen zijn. Zo moet een applicatie expliciet de toestemming krijgen om bepaalde resources of diensten te mogen gebruiken, zoals de return channel, de tuner, het persistente geheugen, etc. Zoals besproken zal worden in hoofdstuk 4.5, kunnen bepaalde maatregelen beperkingen opleggen aan applicaties. Meer informatie over veiligheid in MHP kan gevonden worden in hoofdstuk 13 van [64]. De houding van de gebruiker tegenover tv kan ook voordelen hebben. Al is dit nog niet onderzocht, toch kan verwacht worden dat bij mensen die geen ervaring hebben met gelijkaardige technologie, de leercurve lager zal liggen dan bij de computer. Dit voor drie redenen: 1. de investering is minder aanzienlijk dan bij een pc, wat de angst verkleint om uit te

28 Hoofdstuk 1. Situering 9 proberen; 2. televisie is een vertrouwde omgeving, idtv beginnelingen hebben daarom minder de indruk dat ze alles van nul moeten leren; 3. mensen zijn minder terughoudend om te experimenteren omdat het besturingssysteem niet beschadigd kan worden door een verkeerde handeling. Dit is alles behalve het geval bij bijvoorbeeld het OS Windows. 4. Door de veiligere omgeving hebben de mensen meer vertrouwen. Ze kunnen hun veiligheid moeilijker per ongeluk compromitteren. Dit in vergelijking met de computer waar het risico veel hoger ligt door bijvoorbeeld de draadloze netwerken die standaard onbeveiligd zijn, of door de aanvalstechnieken Phishing en Pharming 1. Een factor waardoor het succes van IM voor tv in gedrang kan komen is het feit dat, in tegenstelling tot werken op de pc, naar de televisie kijken een groepsgebeuren is. Voor interactieve programma s als quizzen of andere competitieve toepassingen kan dit juist een katalysator zijn, maar voor individuele of persoonlijke activiteiten als IM kan het een ernstig probleem vormen. Het is moeilijk om van IM een groepsgebeuren te maken omdat elke persoon uit de groep (bv. een gezin) geïnteresseerd kan zijn om met een ander contact te communiceren. IM blijft hierdoor een zuiver individuele bezigheid en zal het waarschijnlijk als storend worden ervaren door de andere kijkers. IM zal dus waarschijnlijk op sociaal vlak een heel andere rol moeten spelen dan op de pc wil het idtv veroveren. Of IM voor tv, ondanks deze beperking en het probleem van de invoermogelijkheid, de hoge verwachtingen, die werden besproken in 1.3, zal inlossen is nog maar de vraag De vereisten van een IM-applicatie voor idtv In dit hoofdstuk wordt besproken aan welke vereisten een IM-applicatie voor idtv moet voldoen om succesvol te zijn. Bij de bespreking zal een onderscheid gemaakt worden tussen twee soorten vereisten: functionele vereisten en kwaliteitsvereisten. 1 Zowel Phishing als Pharming hebben tot doel gevoelige gegevens te verwerven. De aanvaller doet zich daarbij voor als een betrouwbare partij. Bij Phishing gebeurt dit door berichten te versturen, bij Pharming door een website na te bouwen

29 Hoofdstuk 1. Situering Functionele vereisten Uiteraard moet de ontwikkelde IM-applicatie de klassieke functionaliteiten van een IMsysteem aanbieden: 1. het opzetten, vernietigen en beheren van een account; 2. de presence-informatie kunnen aanpassen en de lijst van contacten beheren die deze informatie mogen zien; 3. (real-time) berichten versturen en chatten met één of meerdere gebruikers (multiuser chat of chatrooms). Naast deze basis functionaliteiten zijn er twee extra functionaliteiten die onmisbaar zijn voor de implementatie van IM voor tv. Namelijk het aanraden van tv-programma s door middel van programma-aanbevelingen, en het kenbaar maken aan de contacten naar welk programma de gebruiker aan het kijken is. Een laatste eis waaraan moeilijker beantwoord kan worden, is het vermogen om te communiceren met andere toestellen en IM-diensten. Dit kan echter een zeer belangrijke functionaliteit zijn. Enerzijds zullen gebruikers zonder ervaring makkelijker het voordeel van IM inzien omdat ze met meer mensen kunnen communiceren. Anderzijds gaan ervaren IM-gebruikers gemakkelijker overschakelen naar tv omdat ze nog altijd met hun oude contacten kunnen communiceren zonder dat die zich moeten aanpassen. Iedereen kan dus aan zijn eigen tempo het nieuwe platform ontdekken zonder dat een hele communauteit simultaan dient te migreren. Deze functionaliteit legt jammer genoeg ook beperkingen op. Er moet bij het ontwerp van de IM toepassing rekening gehouden worden met het feit dat communicatie met een breed gamma aan toestellen met andere eigenschappen, mogelijk moet zijn. Door de betere invoermogelijkheden van een computer zal een gebruiker waarschijnlijk aan een hogere frequentie berichten versturen. Dit kan bijvoorbeeld een invloed hebben op de manier waarop berichten op het scherm getoond worden. Het betekent ook dat de functionaliteiten specifiek aan idtv ook compatibel moeten zijn met de andere toestellen.

30 Hoofdstuk 1. Situering 11 De mogelijkheden om de IM-client of protocollen specifiek aan te passen voor het idtv platform zijn daarom veel beperkter. Een functionaliteit die af te raden is, is archivering, oftewel het bijhouden van de verstuurde berichten. Omdat de IM voor idtv waarschijnlijk in het merendeel van de gevallen alleen voor recreatieve doeleinden zal gebruikt worden is dit een redelijke beslissing. De berichten zouden dan opgeslagen moeten worden op een server vermits het geheugen van de STB veel te beperkt is. Dit brengt weer een extra kost met zich mee. Zouden er toepassingen bestaan waarvoor deze functionaliteit toch nuttig blijkt te zijn, kan men het nog altijd aanbieden als optie. In [46] wordt een manier voorgesteld om deze functionaliteit aan te bieden Kwaliteitsvereisten Prestatie is een belangrijk aspect van een IM-systeem door het real-time karakter ervan. In tegenstelling tot is het kritisch dat de berichten binnen een termijn van een paar secondes worden afgeleverd. De maatregelen die we hiervoor kunnen treffen hangen af van de gekozen technologie. Zo zullen bij een client-server systeem de prestaties van de server bepalend zijn, terwijl de nadruk volledig op de client zal liggen in een peer-to-peer (p2p) systeem. Het netwerk is echter de belangrijkste factor omdat de vertragingen heel sterk kunnen variëren. Er wordt echter niet ingegaan op de maatregelen die voor het netwerk genomen kunnen worden omdat dat buiten de doelstelling van deze thesis ligt. Bovendien is het volledige netwerk niet altijd onder de controle van de ontwerper van de toepassing (bv. open netwerken). Door de beperkte rekenkracht en geheugen van STBs moet het gedeelte van het systeem dat op de STBs uitgevoerd wordt zo weinig mogelijk belastend zijn. Dit vormt in het algemeen geen probleem voor een klassieke IM-applicatie omdat de frequentie waaraan de berichten worden uitgewisseld eerder laag ligt. Als men de IM echter ook voor andere toepassingen wil gebruiken, bijvoorbeeld voor interapplicatie-communicatie zoals besproken in 3.2, kan dit wel een probleem vormen omdat het aantal berichten dan significant hoger kan liggen.

31 Hoofdstuk 1. Situering 12 Om de veiligheid en privacy te garanderen zal de toepassing ook authenticatie moeten ondersteunen. We kunnen voor dezelfde doeleinden gebruik maken van andere maatregelen, zoals encryptie om de berichten onleesbaar te maken voor derden, of hashes toevoegen om de integriteit van de berichten te garanderen. Men moet hierbij wel opletten dat de prestaties van het systeem niet in het gedrang komen aangezien deze technieken in het algemeen veel rekenkracht vergen. Bovendien is het nut ervan toch beperkt door het recreatieve karakter van IM voor tv. Een kwaliteitscriterium dat subjectiever is, en daarom ook moeilijker te bereiken, is gebruiksvriendelijkheid (usability). Al is het moeilijk om concrete maatregelen te nemen, toch moet er zeker aandacht aan besteed worden. Artikels als [38] of [72] kunnen hierbij een goed hulpmiddel vormen. Een laatste criterium dat ook kan bijdragen tot de gebruiksvriendelijkheid is de beschikbaarheid van een dienst (availability). Een dienst die regelmatig niet bereikbaar is kan haar aantrekkingskracht al snel verliezen en een slechte reputatie krijgen. Er bestaan een aantal zeer doeltreffende maatregelen voor servers in een client-server systeem zoals bv. redundantie (passief en actief). Een gedetailleerde bespreking van de kwaliteitsattributen en de tactieken om ze te bereiken kan men vinden in [5]. RFC 2779 [17] bespreekt in detail de minimale vereisten waar een IM-systeem aan moet voldoen. 1.6 Implementatiekeuze Voor de implementatie wordt er gekozen voor de Jabber Instant Messaging en Presence technologie, gebaseerd op het XMPP protocol. In volgend hoofdstuk wordt deze technologie in detail toegelicht en vervolgens vergeleken met andere technologieën en implementatiemogelijkheden.

32 Hoofdstuk 2 XMPP/Jabber 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-clients 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 IM-standaard te ontwikkelen en de interoperabiliteit te bevorderen tussen de verschillende bestaande IM-systemen. Het project evolueerde snel en de eerste versie van de referentieserver was een feit in mei In mei 2001 werd de Jabber Software Foundation (JSF) opgericht, die zich enkel bezig houdt met de ontwikkeling en het beheer van standaarden en niet meer met de ontwikkeling van software. In 2004 werden dan uiteindelijk de Jabber basis protocollen aanvaard als IETF standaard onder de naam Extensible Messaging and Presence Protocol (XMPP). Voor meer informatie over de geschiedenis van Jabber zie [128], [92] en [109]. Voor meer informatie over JSF zie [44]. In dit hoofdstuk wordt XMPP besproken. Om beter de mogelijkheden van deze technologie te kunnen inschatten zal de werking ervan in detail bekeken worden. Daarna worden de voordelen en nadelen ervan in het algemeen besproken, maar ook specifiek voor idtv. Vervolgens wordt XMPP met verschillende andere protocollen en implementatiemogelijkheden vergeleken. Tenslotte worden de toekomstperspectieven van Jabber overlopen. 13

33 Hoofdstuk 2. XMPP/Jabber XMPP: werking De netwerkarchitectuur Hoewel er geen bepaalde netwerkarchitectuur opgelegd is in de standaard, toch wordt XMPP meestal geïmplementeerd als een client-server architectuur met gedistribueerde servers over een TCP-verbinding. Deze eenvoudige en beproefde netwerkarchitectuur ligt ook aan de basis van (SMTP protocol). Elke client communiceert enkel met de server van zijn domein en alle interdomein-communicatie gebeurt enkel tussen servers. Om dit te verduidelijken wordt in figuur 2.1 de reisweg getoond van een bericht van naar levert het bericht af aan de server van zijn domein (jabber.org)(1), deze server geeft het bericht door aan de server van het domein van de ontvanger (hoekman.be)(2), die tenslotte het bericht aflevert bij de geadresseerde gebruiker (3). Figuur 2.1: Illustratie van de reisweg van een XMPP bericht XMPP adressen In XMPP is elke netwerk-entiteit 1 uniek geadresseerd. Een XMPP adres, om historische redenen ook JID (Jabber Identifiers) genoemd, is opgebouwd uit verschillende onderdelen: 1 Een netwerk-entiteit is een netwerk-eindpunt dat kan communiceren aan de hand van XMPP. Het kan zowel een client als een dienst zijn.

34 Hoofdstuk 2. XMPP/Jabber 15 een domain identifier, een node identifier en een resource identifier. Het wordt geschreven als <node identifier>/<resource identifier>. De betekenis van de identifiers hangt af van het type van de entiteit. Zo is in het geval van een client de domain identifier de server waarmee de client verbonden is en de node identifier de naam waarmee de gebruiker ingelogd is (bv. Een gebruiker kan meerdere resource identifiers hebben die elk een ander netwerkeindpunt vertegenwoordigen. We komen terug op de rol van resources in Is de entiteit daarentegen een multi-user chat dienst, dan is de domain identifier de naam van de server die de dienst aanbiedt en de node identifier de naam van de chatroom. De verschillende gebruikers in de chat room kunnen dan geadresseerd worden door hun bijnaam in de chat room te gebruiken als resource identifier, dus XML-streams De kracht van XMPP schuilt in het feit dat XML gebruikt wordt om de data te formatteren. In tegenstelling tot wat men misschien verwacht worden hierbij geen XMLdocumenten op het netwerk uitgewisseld, maar maakt XMPP gebruik van XML-streams. Een XML-stream is een unidirectionele container om XML-elementen (en niet documenten!) te sturen van de initiator van de stream naar de ontvanger. Een XML-stream wordt geopend door een XML <stream> tag te sturen met de nodige attributen en namespace declaraties, van de initiator naar de ontvanger. De stream wordt terug gesloten door een </stream> tag. Tijdens het leven van een stream kan de initiator een onbeperkt aantal XML-elementen sturen. Dit zijn ofwel elementen die bepaalde eigenschappen van de stream onderhandelen (bv. authenticatie of encryptie) ofwel XML-stanzas 2. Omdat een stream unidirectioneel is moet de ontvangende entiteit een stream initiëren in de omgekeerde richting (de antwoordstream) om bidirectioneel informatie te kunnen uitwisselen. In het geval van client-server communicatie wordt de eerste stream geïnitieerd door de client. De volgende tag is een voorbeeld van initiatie door de client met als ontvanger de server jabber.com: <stream:stream to= jabber.com xmlns= jabber:client 2 de eerste niveau kind-elementen dat over een XML-stream gestuurd worden, zie ook 2.1.4

35 Hoofdstuk 2. XMPP/Jabber 16 xmlns:stream= version= 1.0 > Het to attribuut bevat de naam van het domein van de server dat de klant probeert te bereiken. Dit is niet overbodig omdat één fysieke server de rol kan spelen van meerdere XMPP servers, elk voor een verschillend domein. Als reactie op de stream tag van de client initieert de server een antwoordstream: <stream:stream xmlns= jabber:client xml:lang= en xmlns:stream= from= jabber.com id= D D3 version= 1.0 > Het id attribuut bevat een sessiesleutel die uniek is voor de server. Het version attribuut is de versie van het protocol. In het geval van een client-server model kan de client enkel een stream opzetten met zijn server. Toch kan een client naar elke entiteit stanzas sturen zoals te zien is op figuur 2.2. De gebruiker stuurt een stanza via de reeds geïnitieerde stream naar de server (1). Als de geadresseerde gebruiker ingelogd en lokaal is, stuurt de server hem de stanza door de bestaande stream (2a). Is de geadresseerde niet-lokaal, dan moet de stanza eerst gestuurd worden van de server van de zender naar de server van de ontvanger. Hiervoor wordt een stream opgezet tussen de zendende server en de ontvangende server (2b). Pas dan kan de stanza afgeleverd worden aan de ontvanger (3b) XML-stanzas en de kernprotocollen van XMPP Door een XML-stream worden ofwel elementen die bepaalde eigenschappen van de stream onderhandelen gestuurd ofwel XML-stanzas. XML-stanzas zijn eerste niveau kind-elementen van de <stream/> tag. Er bestaan drie verschillende soorten stanzas: de <message/> stanza, de <presence/> stanza en de <iq/> stanza a de <message/> stanza: het berichtgevingsprotocol Deze stanza is een push mechanisme dat een entiteit toelaat om real-time informatie te sturen naar andere entiteiten.

36 Hoofdstuk 2. XMPP/Jabber 17 Figuur 2.2: Reisweg van een XMPP bericht door de XML-streams naar een lokale (a) en nietlokale gebruiker (b). Er bestaan verschillende typen berichten: chat: een bericht verzonden in het kader van een één op één conversatie; groupchat: een bericht verzonden in de context van een multi-user chat omgeving; normal: een enkel bericht dat buiten het kader van een conversatie wordt verstuurd en waarop een antwoord verwacht wordt (dit is de default waarde); headline: een bericht hoogstwaarschijnlijk verstuurd door een geautomatiseerde dienst en waarop geen antwoord verwacht wordt; error: om te melden dat er een fout is opgetreden bij het versturen van een vorig bericht.

37 Hoofdstuk 2. XMPP/Jabber 18 Men kan het type van het bericht opgeven door het attribuut type één van de opgesomde waarden te geven. De waarde van het <thread/> element van een bericht verstuurd in het kader van een converatie, identificeert eenduidig de conversatie waartoe het bericht behoort b de <presence/> stanza: het presence-protocol Een eerste taak van de <presence/> stanza is om de presence-informatie te formatteren. Voor de basisinformatie gebruikt men het type attribuut van de stanza: deze komt niet voor wanneer de entiteit beschikbaar is en heeft de waarde unavailable zoniet. Beschikbare entiteiten kunnen een meer gedetailleerde beschrijving van de toestand opgeven aan de hand van de <show/> en <status/> subelementen. Indien het <show/> subelement niet aanwezig is, is de entiteit beschikbaar, anders kan men kiezen uit één van de volgende waarden: away : de entiteit is even afwezig; chat : de entiteit wil graag chatten; dnd (do not disturb): de entiteit is bezig, niet storen; xa (extended away): de entiteit is afwezig voor een lange periode. Bij het <status/> subelement daarentegen kan men een vrij gekozen tekst opgeven die de toestand toelicht zoals bijvoorbeeld in vergadering, in de les, aan mijn thesis aan het schrijven, enz. Wanneer een entiteit zijn presence-informatie wil verzenden kan dat via twee mechanismen. Hij kan de informatie naar één bepaalde entiteit sturen door de JID ervan op te geven als waarde van het to attribuut. Komt dit attribuut niet voor in de stanza, dan wordt de informatie gebroadcast naar alle geïnteresseerden die hiervoor de toestemming hebben gekregen van de entiteit. Een voorbeeld van een presence-stanza die presenceinformatie bevat van de beschikbare gebruiker user@jabber.org is de volgende:

38 Hoofdstuk 2. XMPP/Jabber 19 <presence from= > <status>ik ben in een vergadering</status> <priority>10</priority> <show>dnd</show> </presence> Op de betekenis van het subelement <priority/> komen we in terug. De broadcast wordt uitgevoerd door de server, die een lijst bijhoudt van entiteiten die op de hoogte willen blijven van de beschikbaarheid van de gebruiker in kwestie. Zo een lijst wordt in het Jabber-jargon een roster genoemd en is beter bekend onder de naam buddy-list. Het inschrijven op een roster en toekennen van toestemmingen gebeurt ook aan de hand van presence-stanzas. Omdat de stanzas hier gebruikt worden in een andere context kunnen ze andere waarden aannemen voor hun type attribuut: suscribe : een aanvraag voor inschrijving. Met de volgende stanza maakt een entiteit bijvoorbeeld kenbaar dat het zich wil inschrijven op de roster van kevin@hoekman.be: <presence to= kevin@hoekman.be type= subscribe /> unsubscribe : de aanvrager maakt de inschrijving op de roster van een entiteit ongedaan. subscribed : de eigenaar van de roster keurt de aanvraag voor inschrijving goed. unsubscribed : de eigenaar van de roster weigert de aanvraag of maakt een bestaande inschrijving ongedaan. Dit wordt uitgebeeld in toestandsdiagramma 2.3. De presence-stanzas worden in deze context altijd van één entiteit naar een ander gestuurd (namelijk tussen de aanvrager en de eigenaar van de roster). De server moet daarom de berichten afluisteren om de roster te kunnen aanpassen.

39 Hoofdstuk 2. XMPP/Jabber 20 Figuur 2.3: Toestandsdiagramma van de inschrijving op een roster. De presence-stanzas worden verder alleen nog gebruikt om presence-fouten te melden. Het type attribuut heeft dan de waarde error en de stanza bevat een subelement error die een beschrijving van de fout bevat. Volgende stanza is daar een voorbeeld van: <presence type= error from= to= > <error type= cancel > <gone xmlns= urn:ietf:params:xml:ns:xmpp-stanzas /> </error> </presence> c de <iq/> stanza: het overige protocol IQ (Info/Query) is een eenvoudig en uitbreidbaar protocol. Het handelt de taken af die niet onder de verantwoordelijkheid vallen van de twee andere stanzas. IQ houdt in dat een entiteit via een request/response mechanisme aanvragen kan sturen naar een andere entiteit (net als http).

40 Hoofdstuk 2. XMPP/Jabber 21 Er bestaan verschillende types IQ-stanzas die worden bepaald door de waarde van het type attribuut: get : een aanvraag naar informatie of vereisten; set : vereiste data verstrekken, nieuwe waarden instellen of oude waarden vervangen; result : het antwoord indien de overeenkomstige aanvraag succesvol was; error : het antwoord indien er een fout is opgetreden bij het verwerken of de aflevering van de overeenkomstige aanvraag. Omdat een entiteit niet moet wachten op een antwoord voordat het een nieuwe stanza stuurt, moet men kunnen weten met welke vraag een antwoord overeenkomt. Dit gebeurt aan de hand van het id-attribuut dat dezelfde (unieke) waarde heeft voor zowel vraag als antwoord. Het IQ protocol specificeert echter enkel het interactie-mechanisme en niet de inhoud van de stanza en is daarom eerder een enveloppe voor de eigenlijke vraag (de query). De inhoud wordt gevormd door nul of meer query subelementen met een welbepaalde namespace, die de IQ extensie eenduidig identificeert. Dankzij dit mechanisme is de IQstanza gemakkelijk uitbreidbaar. Sommige IQ extensies zijn onderdeel van de XMPP standaard ([87] en [88]). Om het principe van IQ extensies te illustreren zal een voorbeeld in detail besproken worden, namelijk de extensie voor Roster Management. Extensie: Roster Management We hebben in b besproken dat men door middel van presence-stanzas presenceinformatie kan sturen en inschrijvingen op de roster kan beheren. Er zijn echter nog drie andere taken die moeten kunnen uitgevoerd worden om tot een compleet presence-systeem te komen. Dit gebeurt aan de hand van het roster protocol dat gebruik maakt van IQstanzas, om precies te zijn van het query subelement en de namespace jabber:iq:roster. De drie taken zijn:

41 Hoofdstuk 2. XMPP/Jabber 22 een kopie van de roster opvragen (bijvoorbeeld bij het inloggen). De volgende stanza is daar een voorbeeld van: <iq from= type= get id= roster1 > <query xmlns= jabber:iq:roster /> </iq> Een mogelijk antwoord van de server is dan: <iq to= type= result id= roster1 > <query xmlns= jabber:iq:roster > <item jid= name= Veronique subscription= both > <group>friends</group> </item> <item jid= name= Michiel subscription= from > <group>friends</group> </item> </query> </iq> een roster item toevoegen of aanpassen: <iq from= type= set id= roster2 > <query xmlns= jabber:iq:roster > <item jid= name= Tom > <group>friends</group> </item> </query> </iq> De server antwoordt hierop: <iq to= type= result id= roster2 /> en stuurt de veranderingen door naar alle resources van de gebruiker die een kopie

42 Hoofdstuk 2. XMPP/Jabber 23 van de roster hebben opgevraagd (bv. en <iq to= type= set id= a78b4q6ha463 > <query xmlns= jabber:iq:roster > <item jid= name= Tom > <group>friends</group> </item> </query> </iq> en <iq to= type= set id= a78b4q6ha463 > <query xmlns= jabber:iq:roster > <item jid= name= Tom > <group>friends</group> </item> </query> </iq> Elke resource die deze stanza ontvangt moet hierop reageren met een IQ-stanza van het type result of error. Bv.: <iq from= to= hoekman.be type= result id= a78b4q6ha463 /> en <iq from= to= hoekman.be type= result id= a78b4q6ha463 /> een roster item verwijderen: <iq from= type= set id= roster4 > <query xmlns= jabber:iq:roster > <item jid= name= Tom subscription= remove />

43 Hoofdstuk 2. XMPP/Jabber 24 </iq> </query> De waarde remove voor het attribuut subscription in het subelement item duidt aan dat het item verwijderd moet worden. Het protocol dat daarop volgt is identiek aan het toevoegen of aanpassen van items: de server bevestigt aan de hand van een IQ response, stuurt de verandering door naar alle resources die een kopie van de roster hebben opgevraagd, die er dan op antwoorden. Meer informatie over de werking van XMPP kan gevonden worden in de specificaties van XMPP: [87] (RFC 3920) en [88] (RFC 3921), en in [109], [92] en [25]. 2.2 Voordelen Uit het vorige hoofdstuk bleek al dat XMPP voldoet aan de vooropgestelde vereisten. Een ervan in het bijzonder wordt besproken in paragraaf Daarnaast bevat het ook bijzondere karakteristieken die het extra geschikt maken voor idtv. Deze worden besproken in de twee volgende paragrafen. Vanaf paragraaf worden de andere voordelen van XMPP die minder specifiek zijn voor idtv bekeken Voldoet aan de vereisten Eén van de moeilijkst te bereiken functionele vereisten is het communiceren met andere IM-diensten. Dit is in XMPP mogelijk dankzij zogenaamde transporten (ook gateways of bridges genoemd). Een transport is een Jabber dienst die de vertaling verzorgt tussen het XMPP-protocol en een welbepaald ander IM-protocol. Er bestaan transporten naar veel verschillende IM-diensten en protocollen zoals Yahoo Messenger, AIM, IRC, MSN Messenger en SIMPLE. Hierbij moet worden opgemerkt dat niet alle XMPP-servers transporten ondersteunen. Het is echter wel mogelijk om gebruik te maken van transporten van andere servers dan diegene waarop men ingelogd is.

44 Hoofdstuk 2. XMPP/Jabber 25 Er bestaan niet alleen transporten naar andere IM-diensten maar ook naar andere diensten zoals SMS of . Figuur 2.4 illustreert de werking van een transport. Voor meer informatie zie [106] Lightweight clients Een eerste aspect dat XMPP bijzonder interessant maakt voor idtv, is dat de protocollen het ontwikkelen van een eenvoudige client mogelijk maken. Dit wordt enerzijds bereikt door te kiezen voor eenvoudige protocollen en beperkte communicatie scenario s (enkel client/server en server/server). Anderzijds kunnen dankzij de client/server architectuur de taken van de client tot een minimum beperkt worden. Zo vallen de volgende zaken volledig onder de verantwoordelijkheid van de server: beheren van de roster en het account, doorsturen en broadcasten van de presence-informatie, de stanzas routen, gebruikers- of configuratiegegevens opslagen. Er zijn drie grote voordelen verbonden aan deze keuze: 1. XMPP-client ontwikkelaars moeten minder aandacht besteden aan het implementeren van de protocollen aan client-zijde en kunnen zich daarom meer richten op de andere belangrijke aspecten zoals bijvoorbeeld gebruiksvriendelijkheid; 2. eenvoudige protocollen moedigen ontwikkelaars aan om client libraries te implementeren voor verschillende programmeertalen, platformen en besturingssystemen; 3. voor embedded en andere omgevingen met beperkte resources kunnen er eenvoudige en lichte clients gebouwd worden. Er zijn ook specifieke ontwerpsbeslissingen genomen in de protocollen in deze optiek. Zo is de client bijvoorbeeld niet verplicht om de roster op te laden bij het inloggen, omdat dit in een omgeving met beperkte bandbreedte voor problemen kan zorgen (zie hoofdstuk 7.3 van [88]). Omdat een STB beperkte resources heeft (zie 1.4.1) is vooral dit laatste voordeel heel belangrijk voor idtv.

45 Hoofdstuk 2. XMPP/Jabber Veiligheid en Privacy Zoals besproken in zijn veiligheid en privacy belangrijke thema s voor idtv. Ook in XMPP is er veel aandacht aan besteed: 1. Volgens de XMPP specificaties is de ondersteuning van SASL [67] voor authenticatie en van TLS [24] voor encryptie verplicht in de client. 2. Omdat de client enkel met de server kan communiceren, is rechtsreeks contact tussen twee clients onmogelijk. Daardoor blijven gevoelige gegevens zoals de locatie van de client verborgen voor andere gebruikers. In tegenstelling tot peer-to-peer netwerken, hoeven de clients ook niet de rol van server te spelen, wat hen behoedt tegen een reeks aanvalstechnieken die toepasbaar zijn op servers. Bovendien zijn er geen problemen met firewalls of NAT, omdat de verbinding met de server geïnitieerd wordt door de client. 3. Volgens het protocol is de server van de zender van een stanza verplicht om het oorsprongsadres in het from attribuut van de stanza op te geven. Daardoor is adresspoofing onmogelijk wat een efficiënte preventieve maatregel is tegen de propagatie van spam op het XMPP netwerk. 4. XMPP ondersteunt met de IQ extensie jabber:iq:privacy het blokkeren van gebruikers. Een belangrijke opmerking is dat de pakketten geblokkeerd worden ter hoogte van de server van de ontvanger en niet door de ontvanger zelf, waardoor clients met beperkte bandbreedte of rekenkracht niet overbelast kunnen worden. Deze extensie maakt deel uit van XMPP en staat gedefinieerd in hoofdstuk 10 van RFC 3921 [88]. 5. Resources worden bij chatrooms (of multi-user chats) handig gebruikt om de anonimiteit van de deelnemers te garanderen. Om met elkaar te kunnen communiceren krijgen de deelnemers namelijk een andere JID bij het toetreden van de chatroom. Deze JID is opgebouwd uit het adres van de chatroom, <dienst>@<server>, met als resource de bijnaam van de gebruiker in de chatroom. Een deelnemer kan berichten sturen naar alle deelnemers door als bestemming het adres van de chatroom op te geven, of naar een specifieke gebruiker door het naar <dienst>@<server>/<bijnaam>

46 Hoofdstuk 2. XMPP/Jabber 27 te sturen. Deze ontwerpskeuze is bijzonder interessant voor social networking en dus voor idtv: mensen kunnen vrijblijvend (want anoniem) chatten met vreemden en indien ze iemand leren kennen die hun interesseert kunnen ze hun echte XMPP-adres geven. XMPP heeft nog vele andere voordelen die minder specifiek zijn aan idtv, maar daarom niet minder interessant Een open internet standaard gebaseerd op XML Jabber werd in 2004 door het IETF [39] aanvaard als internet standaard onder de naam XMPP. Het protocol is gespecificeerd in 4 documenten: RFC 3920 [87], 3921 [88], 3922 [90] en 3923 [86]. Dankzij de standardisering zijn alle XMPP-clients interoperabel en dit onafhankelijk van het platform en toestel. Hierdoor kunnen alle apparaten waarvoor een XMPP-client bestaat (pc, gsm, pda etc.) met elkaar communiceren. In tegenstelling tot de meeste andere IM-protocollen is XMPP een open standaard en bovendien ook patent-vrij. Dit heeft grote voordelen: de standaard is vrij beschikbaar, goed gedocumenteerd en mag vrijblijvend geïmplementeerd worden. XMPP steunt voor verschillende doeleinden, maar vooral voor het formatteren van zijn berichten, op de open W3C ( standaard XML [8] en kan daardoor meegenieten van de voordelen ervan. Omdat XML gestructureerd en ook gemakkelijk leesbaar is voor de mens zijn XMPP berichten eenvoudig en snel te begrijpen. XML is ook flexibel: het kan gebruikt worden in vele contexten en in tegenstelling tot binaire formaten kan de syntax van de berichten gemakkelijk uitgebreid worden zonder de compatibiliteit te verliezen met vorige versies. XML is bovendien ook overdraagbaar, maar het grootste voordeel ervan is zijn populariteit. Dankzij deze populariteit zijn er veel hulp-programma s beschikbaar, zijn er veel ontwikkelaars mee vertrouwd en zorgt het voor een snellere aanvaarding van XMPP.

47 Hoofdstuk 2. XMPP/Jabber Extra functionele- en kwaliteitsattributen Een interessante functionaliteit van XMPP is de store and forward support. Dit betekent dat clients die offline zijn toch berichten kunnen ontvangen omdat die worden opgeslagen op de server. Een andere functionaliteit die men niet terugvindt in andere IM-protocollen, is de mogelijkheid om tegelijkertijd met verschillende clients op een account in te loggen. Dit is mogelijk omdat elk account verschillende resources kan hebben, die elk een netwerkeindpunt van de gebruiker zijn. Het adres van een resource is de volledige JID van het account met als resource identifier de naam van de resource is bv. de resource met naam TV van het account Om te beheren welke resource de berichten ontvangt, wordt er aan elke resource een prioriteit toegekend. De resource met de hoogste prioriteit ontvangt standaard alle berichten. Het is echter ook mogelijk om berichten te sturen naar een specifieke resource door in het bestemmingsadres ook de resource identifier op te geven. De prioriteit van een resource wordt samen met de andere presence-informatie meegegeven in een presence-bericht zoals het voorbeeld bericht in b illustreert. Omdat het aantal gebruikers van een IM-systeem snel kan oplopen is schaalbaarheid een belangrijke kwaliteitsvereiste. Schaalbaarheid wordt in XMPP hardwarematig opgevangen door gebruik te maken van de client-server architectuur met gedistribueerde servers. De verantwoordelijkheden van een server zijn enkel beperkt tot zijn eigen gebruikers en andere servers. De vereiste rekenkracht kan dus beperkt worden door het aantal gebruikers erop af te stemmen. Een server met beperkte resources kan zo maar een paar gebruikers toelaten, terwijl dit bij een krachtige server honderden of zelfs duizenden gebruikers kunnen zijn. Door de verantwoordelijkheden op te splitsen in domeinen kan het XMPP netwerk groeien zonder een bepaalde server te overbelasten of massieve rekenkracht of opslagplaats te eisen Quality of service and policy Een voordeel dat voortvloeit uit de client-server architectuur is dat geen enkele instantie de volledige controle heeft over het netwerk. Het is daarentegen wel mogelijk om een

48 Hoofdstuk 2. XMPP/Jabber 29 gecentraliseerde controle te hebben binnen een domein. Dit is interessant voor bedrijven en mission critical omgevingen die zo een bepaalde quality of service kunnen garanderen of policy regels kunnen opleggen Uitbreidbaar Een groot voordeel van XMPP is dat volgens de specificaties (hoofdstuk 2.4 van [88]), de drie types stanzas kunnen uitgebreid worden met extensies zonder de compatibiliteit met de standaard te verliezen. Men kan zo de standaard uitbreiden en aanpassen aan de eigen behoeftes. Hierbij moet worden opgemerkt dat message en presence-stanzas meerdere extensies mogen bevatten in tegenstelling tot IQ-stanzas die er maximum één mogen bevatten. Om elke extensie onmiskenbaar te identificeren hebben ze elk een unieke namespace. De entiteiten die de stanzas routen kunnen dit doen zonder de inhoud ervan te begrijpen en moeten de extensies daarvoor dus niet ondersteunen. Er bestaan reeds vele extensies waarvan sommige tot de XMPP standaard ([87] en [88]) behoren. Andere extensies, voorgesteld als uitbreiding op de XMPP standaard, noemt men JEPs (Jabber Enhancement Proposals). Een deel ervan is finaal en is dus een gestandardiseerde uitbreiding van XMPP (die echter niet tot XMPP zelf behoort). Een volledige lijst van de JEPs en hun status vindt men op [118]. Men kan zelf gemakkelijk extensies toevoegen op voorwaarde dat men een namespace kiest die nog niet in gebruik is. Een voorbeeld van een extensie is JEP-0071 [95] die wordt toegevoegd aan een messagestanza. Deze laat toe om de inhoud van een bericht te formatteren met XHTML 3. Een voorbeeldstanza die deze extensie bevat is de volgende: <message from= to= > <body> Dit is een groene vet-gedrukte tekst!</body> <html xmlns= > <body xmlns= > 3 Omdat de opmaak van IM-berichten in het algemeen vrij beperkt is, wordt enkel een light-versie van XHTML 1.0 ondersteund, XHTML-IM genoemd, en niet de volledige XHTML standaard.

49 Hoofdstuk 2. XMPP/Jabber 30 <span style= color:green;font-weight:bold > Dit is een groene vet-gedrukte tekst! </span> </body> </html> </message> Merk op dat de stanza de inhoud van het bericht ook ongeformatteerd bevat, zodat een client die de extensie niet ondersteunt het bericht toch kan weergeven Bestaande software Het feit dat XMPP een open en patent-vrij protocol is heeft veel ontwikkelaars aangemoedigd om er software voor te schrijven. Daardoor zijn er software en libraries met allerlei licenties beschikbaar voor de meest uiteenlopende programmeertalen (C, C++, C#, COM, Delphi, Flash, Java, Python, Erlang, JavaScript, Mono, Objective-C, Perl, PHP, Ruby, Tcl, etc.) en platformen (AIX, HP-UX, Linux, Solaris, Windows, MacOS X, BSD, Amiga, Palm OS, Windows CE, Symbian, J2ME 4, etc.). Een overzicht van een deel van de bestaande software kan men vinden op [115] voor de clients, [119] voor de servers, [116] voor andere componenten en [117] voor de libaries. Dit impliceert twee voordelen voor de ontwikkeling van een client voor idtv. Enerzijds is het niet nodig om een serversoftware te implementeren en kan men voor het testen en uitvoeren gebruik maken van bestaande servers als jabber.com of jabber.org. Anderzijds kan men voor het ontwikkelen van de client gebruik maken van reeds bestaande libraries. In vergelijken we enkele bestaande libraries. 4 Java 2 Micro Edition

50 Hoofdstuk 2. XMPP/Jabber Nadelen XML Het gebruik van XML brengt enkele nadelen met zich mee. XML is een dataformaat dat heel kwistig omgaat met ruimte en veel redundantie bevat. Hierdoor nemen XMPP berichten onnodig veel bandbreedte in beslag. Omdat de internetverbinding bij idtv echter niet verschilt van die van een gewone computer is dit geen probleem zolang het aantal verstuurde berichten laag blijft. Kritischer op een STB, is het parsen van XML. Sommige XML-parsers vergen namelijk veel resources en voornamelijk geheugen. Maar omdat de parser enkel XMPP pakketten moet kunnen parsen, kan men zich beperken tot een lichte parser. Dit komt enerzijds door het feit dat XMPP maar een kleine subset van de volledige functionaliteit van XML gebruikt (bv. geen validatie nodig). Anderzijds is de opbouw van een XMPP pakket vrij voorspelbaar (bv. door het beperkt aantal soorten stanzas). Het gebruik van XML kan ook tot veiligheidslekken leiden. Dit te meer omdat omgevingen met beperkte resources als een STB gevoeliger zijn voor sommige aanvallen. Door bepaalde maatregelen in te bouwen in de parser kan men dit echter voorkomen 5. De keuze van een XML-parser wordt besproken in Rechtstreekse communicatie tussen clients Zoals gezien in 2.2.3, draagt het feit dat clients niet rechtstreeks met elkaar communiceren toe tot de veiligheid van het protocol. Voor sommige toepassing als bijvoorbeeld het uitwisselen van bestanden, is dit echter nadelig: enerzijds wordt de server overladen met pakketten en anderzijds wordt het uitwisselen van de pakketten vertraagd. Dit probleem kan echter omzeild worden door gebruik te maken van de extensie JEP-0065 [94], die een generiek protocol voorziet om binaire data te streamen tussen twee XMPP entiteiten, of 5 Een parser gaat typisch recursief de kinderen van de knopen parsen. Een bepaalde aanval bestaat erin de diepte van de knopen zo groot te nemen dat de resources uitgeput geraken of een stack overflow optreedt. Men kan dit bijvoorbeeld voorkomen door het aantal mogelijke recursies in de parser te beperken.

51 Hoofdstuk 2. XMPP/Jabber 32 van de extensie JEP [66] die zich meer specifiek toespitst op het uitwisselen van bestanden Quality of service Een ernstige tekortkoming van XMPP is dat de specificaties geen enkele quality of service (QoS)-vereisten opleggen aan de XMPP servers of clients. Erger nog, er is geen enkele gestandardiseerde manier om een bepaald niveau van dienstverlening in te stellen. Concreet heeft men hierdoor op de vier volgende vlakken geen enkele garantie bij het versturen van een bericht: afleveringstijd: of de berichten de geadresseerde bereiken binnen een welbepaald tijd; volgorde: of de berichten in volgorde aankomen; prioriteit: of een belangrijk bericht voorrang krijgt op een bericht met een lagere prioriteit; transactie: of het bericht één keer en slechts één keer wordt afgeleverd. Er kan hierbij opgemerkt worden dat het transportlaagprotocol TCP [75] waar XMPP zich op baseert wel een bepaalde QoS aanbiedt. De volgorde van TCP-pakketten wordt namelijk gerespecteerd en het pakket wordt slechts één keer afgeleverd. Deze garanties zijn niet van toepassing op XMPP omdat de berichten niet alleen over TCP-verbindingen worden gestuurd, maar ook via één of meerdere XMPP servers. Het gebruik van TCP verhoogt echter wel de kans dat de XMPP-stanzas hun bestemming bereiken omdat de pakketten enkel verloren kunnen gaan in de server en niet onderweg, zelfs niet in een overbelast netwerk. De keuze van TCP voor een real-time toepassing is niet zo vanzelfsprekend, aangezien TCP net door de QoS-maatregelen een trager protocol is dan bijvoorbeeld UDP [74]. Een andere oplossing zou kunnen zijn om UDP te gebruiken als transportprotocol en de QoS maatregelen te implementeren op het niveau van de applicatielaag. 6 De extensie JEP-0096 vervangt de verouderde extensie JEP-0066 [94].

52 Hoofdstuk 2. XMPP/Jabber 33 Voor toepassingen waarvoor een minimaal niveau van QoS vereist is kan men de standaard altijd uitbreiden aan de hand van extensies en indien nodig de XMPP servers uitbreiden 7. Er zijn drie JEPs die extra QoS diensten aanbieden: 1. JEP-0022: Message Events [59]. Deze extensie laat toe om bevestigingen aan te vragen en te ontvangen van gebeurtenissen bij het versturen van een bericht. Het betreft de volgende vier gebeurtenissen: het bericht is offline opgeslagen door de server van de bestemmeling; het bericht is afgegeven aan de client van de bestemmeling; het bericht is getoond aan de bestemmeling; de andere deelnemer in een chatsessie is een antwoord op het bericht aan het schrijven. 2. JEP-0079: Advanced Message Processing [60]. Aan de hand van deze extensie kan men regels opgeven voor de verwerking van een bericht door een XMPP server. Een regel bestaat uit een aktie en een trigger -conditie (de voorwaarde waaraan moet voldaan zijn om de aktie uit te voeren). Er zijn drie types trigger-condities gedefinieerd in de JEP: deliver : het bericht wordt afgeleverd op een manier, of aan een account of type account dat overeenkomt met de manier opgegeven als parameter; expire-at : het bericht bereikt de bestemmeling niet in de tijd opgegeven als parameter; match-resource : het bericht wordt afgeleverd aan de resources van de gebruiker zoals opgegeven als parameter, en vier akties: alert : het bericht wordt niet verder afgeleverd en er wordt een verwittiging naar de zender gestuurd; 7 Een voorbeeld van een toepassing die een aanpassing van de servers vergt is een prioriteit toekennen aan de berichten. De servers moeten namelijk het onderscheid kunnen maken tussen pakketten met verschillende prioriteiten en ze anders behandelen.

53 Hoofdstuk 2. XMPP/Jabber 34 drop : het bericht wordt niet verder afgeleverd; error : er wordt een fout gestuurd naar de zender, die de trigger -conditie bevat die de foutmelding geactiveerd heeft; notify : er wordt een verwittiging gestuurd naar de zender, die de trigger - conditie bevat die de foutmelding geactiveerd heeft. Door de condities en de parameters te combineren met de akties kan men kiezen uit 36 regels, waarmee men meer controle krijgt over het afleveren van de berichten en bepaalde QoS garanties heeft (bv. betrouwbare data transport). 3. JEP-0184: Message Receipts [102]. De rol van deze JEP is om ontvangstbevestigingen van een bericht aan te vragen aan en te ontvangen van clients (in tegenstelling tot JEP-0079 die enkel toelaat om bevestigingen te ontvangen van servers). Om dit te doen voegt deze JEP een regel toe aan de extensie uit JEP-0079, waarvan de conditie het verwerken van het bericht door de client is. Al kunnen extensies zeer doeltreffend zijn om een bepaalde QoS niveau te bereiken in gesloten netwerken, toch is hun impact in een open netwerk vrij beperkt. Men kan er in dat geval namelijk niet op rekenen dat de extensies ondersteund worden op heel het netwerk Maturiteit van het protocol en extensies Bij de recente aanvaarding van Jabber als internetprotocol heeft de standaard enkele aanpassingen ondergaan. Een voorbeeld is encryptie, wat vroeger gebeurde met SSL, terwijl XMPP van TLS [24] gebruik maakt. Een overzicht van de verschillen tussen het oude Jabber protocol en XMPP kan men vinden in Appendix D van [87] en Appendix C van [88]. De veranderingen zijn echter nog niet doorgevoerd in alle software. In afwachting is de enige oplossing beide protocollen te ondersteunen. De populaire client Exodus (http: //exodus.jabberstudio.org/) biedt bijvoorbeeld nog steeds de verouderde encryptiemethode aan naast TLS.

54 Hoofdstuk 2. XMPP/Jabber 35 Al is XMPP een redelijk matuur IM-protocol, toch zijn veel extra features toegevoegd als extensie. Deze zijn echter niet opgenomen in de specificaties ([87] en [88]), waardoor de ondersteuning van deze extensies niet vereist is om compatibel te zijn met XMPP. Hierdoor is het ook belangrijk te weten of de bestemmeling de gebruikte extensies ondersteunt. Dit kan men te weten komen met behulp van andere extensies, namelijk JEP-0030: Service Discovery [36] (eventueel uitgebreid met JEP-0128: Service Discovery Extensions [89]), of met JEP-0115: Entity Capabilities [37]. Dat dit niet altijd nodig is wordt duidelijk uit het voorbeeld van de voorbeeldstanza van Dit is vooral geldig voor extensies waarin de zender geen antwoord verwacht. Het komt in de eerste plaats omdat clients niet-ondersteunde extensies negeren. Bovendien zijn de extensies zo ontworpen dat, indien mogelijk, het negeren ervan geen informatieverlies veroorzaakt. In sommige gevallen kan het interessant zijn om toch een service discovery te doen, zelfs voor extensies waarvoor het overbodig lijkt. Zo kan het in een omgeving met beperkte bandbreedte als een GSM bijvoorbeeld nuttig zijn om de extensie die XHTML formattering toelaat (JEP-0071, [95]) enkel te gebruiken indien het ook effectief ondersteund wordt. Een ander probleem dat in de praktijk kan optreden met extensies, is dat sommige nog niet gefinaliseerd zijn maar toch reeds in gebruik zijn genomen zijn. Daardoor kunnen aanpassingen aan de extensie ervoor zorgen dat er implementaties met verschillende versies van de extensie ontstaan. Ondanks deze nadelen zijn extensies voor XMPP echter een noodzakelijk kwaad. Enerzijds zorgen ze ervoor dat het aantal features dat noodzakelijk is voor compatibiliteit met XMPP relatief laag blijft, wat er tenslotte voor zorgt dat XMPP toegankelijk is voor omgevingen met beperkte resources. Anderzijds kan XMPP zich zo uitbreiden naar andere toepassingsdomeinen (zoals bv. bestanden uitwisselen) zonder de basisstandaard te verzwaren. Een andere oplossing zou kunnen zijn om te werken met verschillende profiles van de standaard 8. De toepassingsmogelijkheden van XMPP zijn echter zo ruim dat men niet 8 MPEG 7 is een voorbeeld van standaard dat opgedeeld is in profiles.

55 Hoofdstuk 2. XMPP/Jabber 36 voor deze oplossing kan kiezen zonder aan eenvoud en flexibiliteit in te boeten. 2.4 XMPP versus andere technologieën Peer-to-peer (P2P) en JXTA Een interessant alternatief voor client-server architecturen als Jabber zijn peer-to-peer (P2P) systemen. In deze systemen wordt geen gebruik gemaakt van een centrale server maar zijn alle contacten tussen de clients rechtstreeks. Hierdoor hebben P2P-systemen onbetwistbare voordelen ten opzichte van XMPP: omdat de data-transfers tussen zender en bestemmeling rechtsreeks zijn, zijn ze efficiënter wat snelheid en bandbreedte betreft; er is geen nood aan centrale servers met veel rekenkracht, opslagplaats, geheugen en bandbreedte; ze zijn beter schaalbaar omdat het aantal gebruikers niet afhangt van het aantal sessies dat een server aankan; het feit dat er geen single point of failure is, verbetert de beschikbaarheid en zorgt ervoor dat P2P-systemen robuuster zijn; anonimiteit: de meeste P2P-systemen laten toe om anoniem gebruik te maken van het netwerk. Er zijn echter ook ernstige nadelen verbonden aan het gebruik van P2P-systemen: fat clients: door de afwezigheid van een centrale server vallen alle taken onder de verantwoordelijkheid van de client. Clients zijn daarom veel omvangrijker en vergen dus meer resources. Veiligheid en privacy: omdat alle clients rechtstreeks met elkaar communiceren zijn ze veel meer blootgesteld aan veiligheids- en privacy problemen. Clients hebben bijvoorbeeld moeilijkeden om te functioneren achter firewalls en het IP-adres van clients

56 Hoofdstuk 2. XMPP/Jabber 37 is gemakkelijk te achterhalen. Maar het grootste probleem is dat P2P-systemen veel gevoeliger zijn voor aanvallen dan systemen gebaseerd op het client-server architectuur. Op [126] staat een reeks van mogelijke aanvallen op P2P-systemen opgesomd. Door de afwezigheid van een centrale entiteit is het moeilijk om een controle uit te oefenen op het systeem. Voor sommige toepassingen of omgevingen zoals bedrijven kan dit nochtans zeer belangrijk zijn voor veiligheids- of policyredenen. Omdat er ook geen controle is op de inhoud van de data kunnen virussen en spam zich gemakkelijk verspreiden. Omdat voor alle taken gesteund wordt op (andere) clients is het praktisch onmogelijk om een bepaald niveau van QoS te garanderen. Voor een instant messenger voor IDTV is de keuze tussen P2P en XMPP snel gemaakt. In tegenstelling tot XMPP voldoet P2P namelijk niet aan de vooropgestelde vereisten. Enerzijds zijn de voordelen van P2P vrij onbelangrijk voor de applicatie: de snelheid waarmee data wordt uitgewisseld heeft weinig impact omdat IM-berichten in het algemeen klein zijn; de serversoftware en servers bestaan al... Anderzijds zijn de lacunes van P2P net belangrijke vereisten voor de applicatie, vooral dan veiligheid en privacy, en de belasting van de client. In het domein van P2P is de interessanste technologie waarschijnlijk JXTA (Juxtapose). Het project JXTA [15] werd in 2001 tot het leven geroepen door Sun Microsystems [114] met als doel een standaard, XML-gebaseerde, platform- en taalonafhankelijke verzameling protocollen te ontwikkelen om de interoperabiliteit tussen P2P-toepassingen te bevorderen. Qua filosofie vertonen JXTA en Jabber dus veel overeenkomsten. Meer informatie over JXTA kan men onder meer terugvinden in [22] en [62] SIP en SIMPLE SIP (Session Initiation Protocol)[83] is een IETF protocol. Het is een rendez-vous - technologie die netwerk-eindpunten toelaat om generisch datastromen op te zetten, te wijzigen en te beëindigen. Het wordt meestal gebruikt om multimedia-sessies op te zetten

57 Hoofdstuk 2. XMPP/Jabber 38 (zoals bv. VoIP and video conferencing) en wordt daarom vaak beschouwd als een multimedia technologie. SIP laat het transfereren van de data over aan andere protocollen. SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions)[11] is een reeks extensies op SIP met als doel de ondersteuning van IM toe te voegen. De werking van SIMPLE is uitgelegd in [51]. Het valt op dat XMPP zowel de functionaliteit van SIP als van SIMPLE combineert in één protocol. XMPP bevat namelijk een onderdeel XMPP: Core [87] voor het opzetten van datastromen (XML-streams om specifiek te zijn) dat dus een gelijkaardige rol vervult als SIP, en een onderdeel XMPP: Instant Messaging and Presence [88] dat het vorige uitbreidt met de ondersteuning van IM (door de inhoud van de XML-stanzas vast te leggen) en dus een gelijkaardige rol vervult als SIMPLE. SIP/SIMPLE en XMPP zijn beide technologieën van het IETF en concurreren om dé IMstandaard van de toekomst te worden. SIMPLE heeft in vergelijking echter veel nadelen. De opsomming die nu volgt komt grotendeels uit [93] 9 en [50] 10. Het belangrijkste nadeel van SIMPLE is ongetwijfeld zijn immaturiteit. Niet alleen is dit protocol nog onder ontwikkeling (voor een overzicht van alle drafts zie [40], maar zoals getoond in tabel 2.1 biedt het ook niet alle functionaliteiten aan die XMPP ondersteunt. Dit is ook de belangrijkste reden dat Alcatel het IM-onderdeel van zijn idtv toepassing AmigoTV gebaseerd heeft op XMPP (pp. 6 van [16]). De immaturiteit van SIMPLE heeft ook gevolgen voor zijn interoperabiliteit: bedrijven die SIMPLE willen gebruiken vullen de niet ondersteunde features aan met andere protocollen waardoor de verschillende systemen niet compatibel meer zijn. Zo zijn de implementaties van Microsoft en IBM, de twee grootste voorstanders van SIMPLE, incompatibel. In tegenstelling tot XMPP, dat speciaal ontworpen is voor IM, baseert SIMPLE zich op SIP, een signalling-protocol dat voor andere doeleinden ontworpen is. Dit zorgt voor de nodige tekortkomingen: SIP is architecturaal ingewikkelder dan XMPP. De beschikbaarheid ligt ook lager 9 De referenties van deze website zijn niet allemaal up-to-date. 10 Er moet gewaarschuwd wordt voor de objectiviteit van dit artikel, aangezien het geschreven is door de director van marketing van Jabber, Inc., een bedrijf dat XMPP-gebaseerde oplossingen commercialiseert.

58 Hoofdstuk 2. XMPP/Jabber 39 Basis functionaliteiten XMPP SIP/SIMPLE Presence Standard Standard [80] Single Messages Standard Standard [11] Chat Messages Standard Experimental [10] Buddy-list Standard Experimental [81] Service Discovery Standard Extension [36] Draft [84] Geavanceerde functionaliteiten XMPP SIP/SIMPLE Communications Blocking Standard Unsupported Composing Indicators Draft [105] Draft [107] Capabilities Advertisement Draft [37] Experimental [52] File transfer Draft [66] [31] Service Registration Standard [96] Unsupported Multi-User Chat Draft [91] Unsupported Formatted Messages (XHTML) Draft [95] Unsupported Offline Messages Draft [99] Unsupported Tabel 2.1: Vergelijking van de functionaliteiten beschikbaar in XMPP en SIP/SIMPLE omdat er verschillende servers (locatie-servers, proxies en redirect-servers) nodig zijn voor de verschillende diensten waardoor er meer potentiële points of failure in het netwerk zijn. Doordat SIP geen server-to-server protocol heeft wordt interdomein communicatie ingewikkelder dan nodig, en komt de schaalbaarheid in gedrang. De SIP-header van de pakketten moet ook leesbaar blijven voor de routing, wat encryptie van de data verhindert. Logischerwijze laat SIP niet alleen TCP toe, maar ook UDP. Omdat er geen garantie is dat de IM-berichten over TCP verstuurd worden, moeten de IM-pakketten zich houden aan de lengtebeperkingen van UDP (1300 bytes). Bovendien bestaat bij het gebruik van UDP een grotere kans op pakketverlies (vooral in overbelaste netwerken). XMPP en SIP zijn beide tekstgebaseerde protocollen 11 en daarom ook plaats- en bandbreedte-inefficiënt. Bij SIP is dit echter erger dan bij XMPP: de minimum grootte 12 van een SIMPLE bericht is al gauw 260 bytes in vergelijking met 100 bytes 11 De syntax van SIP is grotendeels gebaseerd op die van het HTTP-protocol. 12 Deze getallen moet met de nodige omzichtigheid geïnterpreteerd worden en zijn niet volledig onpar-

59 Hoofdstuk 2. XMPP/Jabber 40 voor een XMPP bericht. Het contrast is nog groter voor presence-pakketten: 602 bytes voor SIMPLE tegenover 67 bytes voor XMPP. Omdat voor een gebruiker met 100 contacten elke verandering in de buddy-list een data-transfer van 60 kb teweeg brengt, kan dit ernstige gevolgen hebben voor de schaalbaarheid van SIP-systemen (IM-systemen kunnen duizenden tot miljoenen simultane gebruikers hebben). In SIP gebeurt de communicatie standaard P2P, waardoor de in opgenoemde nadelen van P2P-systemen overgenomen worden. SIP gebruikt in tegenstelling tot XMPP enkel ASCII. Daardoor zijn adressen en de inhoud van berichten niet internationaliseerbaar. SIP voorziet geen elegante manier om met NAT en firewalls om te gaan. Bij NAT moeten immers voor alle verstuurde data de private IP-adressen vertaald worden in publieke adressen en vice-versa voor ontvangen data. Bij firewalls is het probleem dan weer dat de meeste media op dynamische poorten en adressen wordt verstuurd. Voor mogelijke oplossingen zie [85] en [82]. Er zijn echter nog andere nadelen, die niets te maken hebben met het feit dat SIMPLE op SIP gebaseerd is: omdat XMPP en SIMPLE beide aanvaard zijn door het IETF, garanderen ze een hoge veiligheid op het protocolniveau. In tegenstelling tot XMPP bestaan er over SIP veiligheidswaarschuwingen over kwetsbaarheden. Er is weinig documentatie en literatuur beschikbaar over SIMPLE. Ondanks het feit dat er in SIMPLE aandacht besteed wordt aan omgevingen met beperkte resources (zie bv. de extensie [71] die toelaat om bij een wijziging in presence van één van de contacten enkel de gewijzigde presence-informatie te ontvangen) is het protocol er toch niet voor geoptimaliseerd. Zo worden buddy-lists bijvoorbeeld beheerd door de client. tijdig. Realistische en uitgemiddelde metingen zouden een meer genuanceerd beeld geven, maar in het algemeen blijft de opmerking wel geldig.

60 Hoofdstuk 2. XMPP/Jabber 41 Ondanks deze vele nadelen was er (tot voor kort) een goede reden om te kiezen voor SIP/SIMPLE, namelijk de ondersteuning van multimedia-extensies. Dit is essentieel voor het aanbieden van een real-time totaaloplossing die IM, VoIP en video-conferencing integreert. Het is vanzelfsprekend dat SIMPLE/SIP multimedia-extensies ondersteunt, omdat dit de bestaansreden van SIP is. Bij XMPP was dit niet het geval omdat er geen protocol voorhanden was om P2P multimedia-sessies op te zetten en te beheren vanuit XMPP clients. Een mogelijke oplossing was om deze lacune op te vangen met SIP (of andere signalling protocollen als H.323, zie bv. Asterisk-IM [4]). Sinds kort (maart 2006) is er echter een nieuw (nog experimenteel) protocol ontwikkeld specifiek voor XMPP onder de naam Jingle [53]. Dit protocol is gelijkaardig aan hetgeen dat gebruikt wordt door Google Talk [33] en er zijn al open-source implementaties geïntegreerd aan sommige XMPP clients (bv. Psi [77]). Omdat Jingle [53] enkel een generisch framework definieert voor het opzetten en beheren van out-of-bound 13 multimedia sessies, en dus noch een data transport methode, noch een mediatype oplegt, moet dit in aparte specificaties gebeuren. Dit zijn: JEP-0167 [54]: specificeert een formaat om Jingle audio sessies te beschrijven; JEP-0176 [6]: definieert een transportmethode om RTP (Real-time Transport Protocol) [108] stromen op te zetten en te beheren tussen XMPP entiteiten; JEP-0177 [7]: definieert een transportmethode om RTP [108] stromen op te zetten en te beheren tussen XMPP entiteiten, gebruik makend van een UDP [74] verbinding; JEP-0179 [13]: definieert een transportmethode om IAX (Inter-Asterisk exchange) [113] sessies op te zetten en te beheren tussen XMPP entiteiten; JEP-0180 [101]: specificeert een formaat om Jingle video sessies te beschrijven; JEP-0181 [100]: specificeert een XML-formaat voor het encapsuleren van DTMFdata in informatieve berichten die uitgewisseld worden in het kader van een Jingle 13 In de context van XMPP betekent out-of-bound communicatie een rechtstreekse (P2P) communicatie tussen twee XMPP clients. Dit in tegenstelling tot in-bound communicatie die verloopt langs minstens één XMPP server.

61 Hoofdstuk 2. XMPP/Jabber 42 audio sessie. Het tegemoetkomen aan de enige tekortkoming van XMPP ten opzichte van SIP/SIMPLE is in eerste plaats een strategische zet. In de praktijk kan de tekortkoming worden opgevangen door XMPP in SIP te behandelen zoals elk ander data-transportprotocol, waarbij de XMPP sessies worden opgezet door SIP (zie bv. de softphone-programma s Gizmo [32] en OpenWengo [73]). Dankzij Jingle is het echter mogelijk om totaaloplossingen te bouwen die volledig gebaseerd zijn op XMPP. Niet alleen zijn XMPP en SIMPLE dus in een strijd verwikkeld om dé IM-standaard van de toekomst te worden, bovendien moet SIP door het ontstaan van Jingle, in de toekomst waarschijnlijk vechten voor zijn voortbestaan. Omdat zowel Jingle als SIMPLE nog immatuur zijn is het moeilijk om lange termijnsvoorspellingen te maken. Er zijn verschillende scenario s mogelijk: 1. SIMPLE wint aan maturiteit en wordt een waardige concurrent voor XMPP. Men heeft dan de keuze tussen twee protocollen waarin IM en multimedia geïntegreerd zijn: SIP/SIMPLE en XMPP/Jingle, of afhankelijk van de vereisten of andere (bv. economische) factoren, uit een combinatie van beide XMPP verdringt SIMPLE en wordt dé IM-standaard. SIP maakt om IM te ondersteunen gebruik van XMPP. 3. XMPP/Jingle verdringt zowel SIMPLE als SIP. Dat SIP XMPP verdringt is hoogst onwaarschijnlijk omdat XMPP reeds veel gebruikers telt en zijn troeven heeft bewezen. Om dezelfde reden is scenario 3 onwaarschijnlijk: SIP heeft een aanzienlijke voorsprong op Jingle en is zeer wijdverspreid. De twee meest realistische scenario s zijn dus scenario 1 en 2. Zonder de steun van Microsoft en IBM zou SIMPLE snel verdwijnen. Microsoft heeft echter hoge verwachtingen van SIMPLE en baseert er zijn real-time bedrijfsoplossingen op, zoals bijvoorbeeld Windows Messenger en de Live Communications Server. Het voorbestaan van SIMPLE zal dus waarschijnlijk 14 Er is reeds een gateway ontwikkeld tussen SIP en XMPP door Jabber, Inc. en [57] bespreekt de vertaling tussen beide protocollen.

62 Hoofdstuk 2. XMPP/Jabber 43 meer strategisch dan technologisch bepaald worden. Zo sloten Microsoft en Yahoo! in October 2005 een overeenkomst om tegen de zomer van 2006 interoperabel te zijn door middel van SIP/SIMPLE. Omdat SIP zo wijdverspreid is, is een Jingle/SIP gateway van cruciaal belang voor het succes van Jingle. Zo kan de overstap naar XMPP/Jingle progressief gebeuren, zonder dat de bestaande SIP-infrastructuur waardeloos wordt, of slechts partieel zijn. Doordat Jingle en SIP op hetzelfde protocol steunen voor het streamen van media (RTP), en de signalling concepten gelijkaardig zijn, zou een gateway tussen Jingle en SIP relatief makkelijk te bouwen moeten zijn. Wat de IM4MHP applicatie betreft, volgt uit de nadelen van SIMPLE en zijn onzekere toekomst dat SIP/SIMPLE geen geschikte kandidaat is RTP Een protocol dat een belangrijke rol speelt bij het uitwisselen van real-time multimedia is RTP (Real-time Transport Protocol) [108]. RTP definieert een gestandardiseerd formaat voor audio- en videopakketten die over een netwerk gestuurd worden. De rol van RTP vertoont dus veel gelijkenissen met die van het onderdeel Instant Messaging and Presence van XMPP [88]: beide protocollen specificeren een manier om data te formatteren in pakketten. Bij RTP is dit binaire, ongestructureerde data, bij XMPP tekst-gebaseerde, gestructureerde data. Ondanks deze gelijkenis zijn RTP en XMPP geen concurrerende protocollen maar in tegendeel complementair. Dit is omdat ze elk geoptimaliseerd zijn voor andere types real-time transfers: rekenintensive, verlies-tolerante datastromen in het geval van RTP, relatief kleine stukjes gestructureerde data tussen twee netwerk eindpunten in het geval van XMPP. Het complementair zijn van SIP, XMPP en RTP wordt in detail besproken in [55], waarin ook een aantal use-cases uitgewerkt zijn. Een voorbeeld van een programma waar de drie protocollen complementair gebruikt worden is Alcatel s AmigoTV[16].

63 Hoofdstuk 2. XMPP/Jabber Gesloten protocollen Vanzelfsprekend zijn gestandaardiseerde protocollen veel aantrekkelijker dan de gesloten protocollen gebruikt door de grootste IM diensten: MSN Messenger, AIM/ICQ en Yahoo! Messenger. De grootste nadelen van gesloten protocollen zijn enerzijds de totale afwezigheid van documentatie en anderzijds het tekort aan interoperabiliteit. De opgesomde diensten hebben er alle baat bij om niet interoperabel te zijn, omdat het een manier is om de gebruikers aan zich te binden en het succes van open-source protocollen te beperken. Bovendien belet het ook dat hun infrastructuur gebruikt wordt door externe gebruikers. Hier begint echter stilaan verandering in te komen: er zijn interoperabiliteitsovereenkomsten tussen Microsoft en Yahoo! (oktober 2005) [41], en tussen Google Talk en AOL [47]. Wie ervoor kiest gesloten protocollen te gebruiken, heeft twee opties: zich binden aan één specifiek protocol of er meerdere ondersteunen (zie bv. Gaim [30]). Omdat het protocol niet publiek is 15, is de enige manier om het te ontcijferen meestal reverse engineering 16, en kan men meestal maar een deel van het protocol benutten. Bovendien is het hierbij opgeletten geblazen voor wettelijke kwesties. Er bestaan twee verschillende manieren om verschillende niet-interoperabele protocollen aan te bieden. De eerste is om ze allemaal te combineren in de IM-client toepassing (zie bv. Gaim). Anderzijds kan men de interactie met de andere IM-diensten overlaten aan de server en blijft het gebruik van andere protocollen verborgen voor de client. XMPP maakt gebruik van deze laatste aanpak door het gebruik van transports. 2.5 De toekomst van XMPP Zoals te zien is in tabel 2.2 heeft XMPP al een zeer groot aantal gebruikers en is het een te vrezen concurrent voor de andere IM-diensten. Deze cijfers moeten echter gerelativeerd worden aangezien XMPP vooral succes heeft in de bedrijfswereld ( gebruikers) 15 Microsoft heeft het MSN Messenger Service 1.0 Protocol echter wel bekend gemaakt, zie [65]. 16 Zie [61] om de methodologie voor gesloten protocollen te achterhalen.

64 Hoofdstuk 2. XMPP/Jabber 45 en in mindere mate op de recreatieve markt ( gebruikers). Het feit dat Google Talk XMPP ondersteunt zou daar snel verandering in kunnen brengen. IM-dienst # actieve gebruikers totaal # gebruikers AIM (aug. 2005) (jan. 2003) MSN Messenger (aug. 2005) (apr. 2005) Skype (sept. 2005) Yahoo! Messenger (sept. 2005) - ICQ Jabber/XMPP QQ (2005) Gadu-Gadu Tabel 2.2: Aantal gebruikers van enkele populaire IM-diensten. Bron: [124]. Zoals besproken in is het te betwijfelen dat XMPP dé unieke IM-standaard zal worden. Ondanks dat zal het succes van XMPP ongetwijfeld nog toenemen en dit niet alleen voor IM-doeleinden. XMPP heeft namelijk een heel breed toepassingsgebied zoals in hoofdstuk 3 besproken zal worden, wat ook deels zijn populariteit bij bedrijven verklaart. Er zijn oplossingen ontwikkeld die gebruik maken van XMPP voor de financiële sector, de amerikaanse regering, de telecomsector, de technologiesector, customer-care, onderwijs, etc. Enkele bedrijven die XMPP-gebaseerde producten gebruiken zijn: Apple, Sun, HP, Oracle, FedEx, EDS, large telcos, Wall Street investment banks, the U.S. Department of Defense, etc. Voorbeelden van projecten zijn beschikbaar op [43].

65 Hoofdstuk 2. XMPP/Jabber 46 Figuur 2.4: Communicatie met een client van een andere IM-dienst door middel van een transport: (a) als de transport zich op dezelfde server bevindt; (b) als de transport zich op een andere server bevindt.

66 Hoofdstuk 3 Andere toepassingsmogelijkheden van XMPP In het vorige hoofdstuk werd XMPP vooral besproken in het kader van IM. XMPP is echter veel meer dan een protocol voor IM alleen: het is een real-time mechanisme om gestructureerde data uit te wisselen. Deze data kan IM-data zijn, maar kan in principe ook gelijk welk ander type data zijn 1, verpakt in een XMPP-pakket. Een andere uitbreiding is om XMPP adressen niet alleen aan mensen toe te kennen, maar ook aan toestellen, computers, routers, servers, terminals, of elke andere entiteit aangesloten op een netwerk. Door deze twee uitbreidingen ontstaan een hele reeks nieuwe opportuniteiten die ook bijzonder interessant kunnen zijn in het kader van idtv. Dit hoofdstuk behandelt de nieuwe mogelijkheden in het algemeen, maar bespreekt ook de voordelen en mogelijkheden specifiek voor idtv. 1 XMPP kan zelfs gebruikt worden om grote hoeveelheden, binaire, ongestructureerde data te vervoeren. Men moet dan wel rekening houden met eventuele alternatieven die beter aansluiten bij de vereisten zoals bv. RTP voor het transferen van VoIP-data. Zie ook

67 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP Flexibel diensten toevoegen door middel van chatbots Voordelen van chatbots Een interessante en flexibele manier om nieuwe diensten aan te bieden zijn chatbots. Een chatbot is een applicatie die zich autonoom gedraagt als een IM-client op een IMnetwerk. De kracht en flexibiliteit ervan schuilt in het feit dat IM-gebruikers via gewone IM-berichten kunnen interageren met een chatbot en zo ook beroep kunnen doen op zijn diensten. Dit heeft verschillende voordelen: gebruikers hebben enkel een IM-client nodig om van de diensten gebruik te kunnen maken; omdat geen extra software vereist is, verhoogt het toevoegen van diensten de vraag naar resources niet. Dit is naturlijk bijzonder interessant voor omgevingen met beperkte resources zoals een STB. De gebruikers moeten bij nieuwe diensten niet leren omgaan met nieuwe programma s zodat de leertijd lager kan liggen. Bij het toevoegen, verwijderen of aanpassen van een dienst moet er geen software geüpdatet worden. Chatbots bieden dus gelijkaardige voordelen als webservices en komen in het geval van XMPP praktisch op hetzelfde neer, omdat ze beide gebruik maken van XML-geformatteerde berichten [109]. Er zijn echter een paar verschillen. Ten eerste maken webservices typisch gebruik van HTTP om problemen met firewalls of NAT te vermijden. Chatbots maken gebruik van het XMPP netwerk dat dit voordeel ook heeft. Ten tweede worden webservices gebruikt door applicaties, terwijl chatbots rechtstreeks gebruikt worden door mensen (zie 3.2 voor het geval chatbots gebruikt worden

68 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 49 door applicaties). Een nadeel van chatbots is dan weer dat er geen standaard manier is om diensten te ontdekken. De types diensten die men door middel van chatbots kan aanbieden zijn virtueel onbeperkt. Enkele interessante diensten voor idtv worden nu uitgewerkt om de potentiële impact van chatbots te illustreren Voorbeelden a Voorbeeld 1: Deelnemen aan een tv-kwis Zoals in 1.3 besproken, is interactiviteit een uiterst belangrijk onderdeel van idtv. Chatbots kunnen een middel zijn om interactiviteit aan te bieden en om dit te illustreren gebruiken we het voorbeeld van een wekelijkse tv-kwis. Een mogelijke aanpak wordt uitgebeeld in figuur 3.1 en is als volgt. Bij het beginnen van het programma (en eventueel ook later) wordt het XMPP-adres van de chatbot opgegeven die in opdracht van het tv-programma werkt. Personen die willen deelnemen registreren zich op de buddy-list van de chatbot. Tijdens de kwis wordt elke vraag die in de studio gesteld wordt ook tekstueel naar de gebruikers gestuurd via de chatbot (1). De deelnemer stuurt het antwoord naar de chatbot (2) die dit bevestigt. De chatbot vermeldt hierbij of het antwoord correct is en ook wat de nieuwe score van de deelnemer is (3). Het correcte antwoord wordt na het aflopen van de tijd gegeven in de studio en enkele statistieken van de thuisdeelnemers worden op het scherm getoond (hoogste score, gemiddelde score, aantal juiste antwoorden...) (4). Na het aflopen van de kwis zet de chatbot zijn status op afwezig. Een dag voor de volgende uitzending stuurt de chatbot een bericht naar alle geregistreerden om hen eraan te herinneren naar de kwis te kijken. In deze use-case kan de afwezigheid van QoS-garanties in XMPP drie kritische problemen veroorzaken. De eerste twee problemen worden enerzijds veroorzaakt doordat er geen garantie is dat een bericht wel effectief aankomt, anderzijds door het feit dat er geen maximumtijd staat op het afleveren van een bericht.

69 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 50 Figuur 3.1: Interactie tussen de deelnemers en de chatbot tijdens een tv-kwis. Het eerste probleem is dat het antwoordbericht van een deelnemer of het bevestigingsbericht van de chatbot verloren kunnen gaan. Hierdoor weet de gebuiker niet of zijn antwoord wordt meegerekend en is het bovendien waarschijnlijk al te laat om het antwoord nog eens te verzenden. Het tweede probleem is dat het antwoordbericht van een deelnemer te laat kan aankomen om nog meegerekend te worden in de statistieken. Dit kan vooral kritisch zijn voor het bepalen van de winnaar. Het laatste probleem is uitgebeeld in figuur 3.2 en is een gevolg van het feit dat er geen vaste afleveringstijd is. 2 Het is daardoor onmogelijk om te bepalen of het antwoord van een deelnemer verzonden is voor of nadat het correcte antwoord bekend gemaakt is, indien het erna ontvangen wordt door de chatbot. Figuur 3.2: Probleem om de verzendtijd van het antwoord te bepalen. 2 Het is onmogelijk een vaste afleveringstijd te garanderen in elk pakket-gebaseerd netwerk. Het probleem is dus algemeen en ligt niet aan het gebruik van XMPP.

70 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 51 We komen in op deze problemen terug b Voorbeeld 2: Gebruikersondersteuning Door het verschil in ervaring tussen computer- en tv-gebruikers (zie ook 1.4.3), is gebruikersondersteuning een belangrijk onderdeel van idtv applicaties. Men kan hiermee verschillende zaken bedoelen: klassieke help-bestanden; een companion guide die de gebruiker stap-voor-stap door de applicatie gidst (zie bv. Microsoft Agents); customer support : vragen van gebruikers kunnen worden afgehandeld door chatbots, indien deze ontoereikend blijken wordt de gebruiker doorverbonden met een menselijke specialist. Chatbots zijn een beter hulpmiddel dan de statische helpbestanden en dit voor twee redenen. Ten eerste is het niet nodig om de bestanden lokaal op te slaan, wat de vereiste opslagplaats op de STB vermindert. De applicatie kan hierdoor ook sneller ontvangen worden via de carousel. Ten tweede zijn chatbots gebruiksvriendelijker: de aangeboden hulp is interactief, waardoor het probleem progressief uitgediept kan worden. Dit kan nog verbeterd worden door de chatbot te voorzien van een vorm van artificiële intelligentie c Voorbeeld 3: Een tekst-gebaseerde -client Het is mogelijk om bepaalde soorten toepassingen op de STB te vervangen door een toepassing die dezelfde diensten aanbiedt op een chatbot. Een beperking van deze methode is dat de interactie met het programma zuiver tekstueel (en dus niet-grafisch) is, en dat het daarom maar interessant is voor sommige types applicaties. De beperkingen van chatbots worden verder besproken in In dit voorbeeld wordt voor een -client gekozen. De manier waarop de gebruiker omgaat met de applicatie is identiek aan die bij andere tekst-gebaseerde programma s

71 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 52 zoals bijvoorbeeld PINE [120]. De communicatie tussen de verschillende entiteiten wordt getoond in figuur 3.3. Figuur 3.3: Uitwisseling van informatie bij het gebruik van een -chatbot d Voorbeeld 4: Informatie opvragen Chatbots kunnen gebruikt worden om informatie op te vragen. De chatbot kan hierbij zelf een databank zijn, of kan als tussenpersoon fungeren om een bestaande databank ter beschikking te stellen van IM-gebruikers. Er kunnen twee mechanismen gebuikt worden voor het verdelen van informatie: een pull-mechanisme: de chatbot antwoordt op vragen van de gebruikers. Dit mechanisme is niet beperkt tot één interactie: de gebruiker kan beginnen met een zeer algemene vraag en op basis van het antwoord nieuwe, preciezere vragen sturen. een inschrijvings-mechanisme: de chatbot stuurt op bepaalde tijdstippen informatie naar alle entiteiten in zijn buddy-list. Gebruikers die geïnteresseerd zijn in de informatie moeten zich dan enkel registreren bij de buddy-list van de chatbot. Een chatbot kan simultaan gebruik maken van beide mechanismen. Een voorbeeld van dienst waar dit van pas zou komen is het aanbieden van beurscijfers. Gebruikers die op

72 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 53 de hoogte willen blijven van de koerswijzigingen van een aandeel kunnen gebruik maken van het inschrijvingsmechanisme. Gebruikers die op een bepaald ogenblik de waarde van een welbepaald aandeel willen weten, maken gebruik van het pull-mechanisme. Andere voorbeelden van informatietypes zijn: de gouden gids, de vluchttijden op Zaventem, de treintijden, de horoscoop, het weerbericht, de lotto-uitslagen, immobiliën, nieuwsbrieven, reispromoties, etc e Voorbeeld 5: Impulsaankopen Een idee dat voorgesteld wordt in [14], is om van chatbots gebruik te maken om verkoopsopportuniteiten te creëeren die gelinkt zijn aan hetgene dat op het tv-scherm getoond wordt. Tijdens een muziekclip stuurt de chatbot de kijker bijvoorbeeld een link om de single bij een muziekwinkel te kopen via t-commerce. De meerwaarde van deze methode is dat praktische problemen wegvallen (winkel zoeken, zich herinneren om te kopen), en dat impulsieve aankopen mogelijk worden Opmerkingen Omdat chatbots rechtstreeks door mensen gebruikt worden, kan het een meerwaarde zijn om een zeker niveau van artificiële intelligentie (AI) in te bouwen, zodat de communicatie op een relatief natuurlijke manier verloopt. Dit kan in het bijzonder interessant zijn voor idtv omdat een deel van de gebruikers weinig of geen ervaring heeft met computersystemen. Een bekend voorbeeldprogramma is A.L.I.C.E. [3], zie ook [122], [123] en [63]. Wanneer men gebruik maakt van gewone berichten om te communiceren met een chatbot, is er voor de chatbot geen manier om te bepalen of er een verband bestaat tussen deze aanvraag en vroegere aanvragen: het uitwisselingsprotocol is context-vrij (stateless). Omdat het communicatieprotocol echter een IM-protocol is, ondersteunt het intrinsiek ook context-rijke (stateful) aanvragen. Het probleem van een context komt namelijk ook voor bij zuivere IM: is een bericht alleenstaand of is het gestuurd in het kader van een conversatie, en zoja, dewelke? Om dit probleem op te lossen gebruikt IM chat-berichten.

73 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 54 Dat dit probleem ook voorkomt bij menselijke communicatie heeft een bijkomend voordeel: gebruikers gaan instinctief de juiste keuze maken tussen beide types berichten om te communiceren met een chatbot. In voorbeelden 1 en 4 werd er stilzwijgend gebruik gemaakt van het presence publishsubscribe systeem van XMPP om informatie te verspreiden. De chatbot moet hierdoor de inschrijvings- en uitschrijvingsfunctionaliteiten niet zelf implementeren. Bovendien wordt als neveneffect van de inschrijving, de dienst toegevoegd aan de roster van de gebruiker. Dit heeft twee voordelen: het adres van de dienst is opgeslagen in de roster en de beschikbaarheid van de dienst is zichtbaar via de presence informatie van de chatbot. Deze inschrijvingsmethode heeft echter zijn beperkingen. Enerzijds is het enkel bruikbaar wanneer elke chatbot maar één dienst aanbiedt. Anderzijds kan men geen argumenten meegeven bij de inschrijving. Zo zou het bijvoorbeeld interessant kunnen zijn om bij de registratie op de beursdienst besproken in d, de aandelen te kunnen opgeven waarin men geïnteresseerd is. Een mogelijk alternatief in XMPP is de extensie JEP-0060[58] dat een generisch publishsuscribe mechanisme voorziet Beperkingen van chatbots De kracht van chatbots vloeit voort uit het feit dat er, naast een IM-client, geen bijkomende software nodig is om van de aangeboden diensten gebruik te kunnen maken. Het is net deze eigenschap die aan de bron ligt van drie beperkingen van deze methode. Als het IM-protocol geen uitgebreide opmaaktaal ondersteunt, is een eerste beperking de weergave van de informatie. In het geval van XMPP is men in het beste geval beperkt tot een light-versie van XHTML 1.0 [95]. Wordt de extensie niet ondersteund door de IM-client, dan wordt alle informatie weergegeven als platte tekst. Chatbots zijn ook beperkt in gebruiksvriendelijkheid omdat alle invoer van de gebruiker tekstueel is. Voor idtv specifiek is dit nog nefaster door de beperkte invoermogelijkheden. De enige invoer die de chatbot ontvangt is de informatie opgegeven door de gebruiker. Hierdoor zijn niet alle types diensten geschikt voor een implementatie aan de hand van

74 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 55 chatbots. Een goed voorbeeld hiervan zijn de problemen die optreden bij de werking van de tv-kwis besproken in a. Zo is het bijvoorbeeld voldoende om het tijdstip waarop de gebuiker antwoordde mee op te nemen in het antwoordbericht, om te kunnen bepalen of het bericht verstuurd werd voor of nadat het correcte antwoord gegeven werd. 3 De andere genoemde problemen kunnen dan weer opgelost worden door bijkomende QoSmechanismen in te bouwen (bv. het antwoordbericht nog eens versturen als binnen de x ms geen bevestiging wordt ontvangen). Om deze beperkingen te omzeilen kan men toegang bieden tot de chatbot via een op maat gebouwde applicatie in plaats van via de IM-client. Deze applicatie kan de informatie op een duidelijke en aantrekkelijke manier representeren, een gebruiksvriendelijke gebruikersinterface voorzien en de nodige mechanismen implementeren. Dit gaat dan echter ten koste van de in opgenoemde voordelen van chatbots. Dit is een speciaal geval van het onderwerp besproken in het volgende hoofdstuk: interapplicatie communicatie via IM-berichten. 3.2 Interapplicatie-communicatie De XMPP-protocollen worden bij IM gebruikt voor communicatie tussen twee mensen en bij chatbots tussen een mens en een toepassing. Niets belet echter om deze protocollen te gebruiken om twee applicaties met elkaar te laten communiceren. De mogelijkheden hiervan worden onderzocht in dit hoofdstuk XMPP als generisch datatransportprotocol Bij het bouwen van een computersysteem waarin verschillende entiteiten met elkaar moeten communiceren, kan, zoals getoond in figuur 3.4, het transporteren van de data overgelaten worden aan het XMPP-protocol. XMPP fungeert dan als een applicatielaag-protocol dat een extra netwerk-abstractie toevoegt. 3 Uiteraard is deze oplossing simplistisch: niet alleen moeten de uurwerken van zender en ontvanger gesynchroniseerd worden, maar bovendien moet er nagekeken worden of het antwoord niet verstuurd is door een onbetrouwbare applicatie.

75 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 56 Figuur 3.4: Datatransport tussen twee applicaties door gebruik te maken van het XMPPprotocol. Er zijn twee verschillende redenen om XMPP te gebruiken in plaats van een ander applicatielaag-protocol of zelfs rechtstreeks een transportprotocol. Ten eerste gebeurt de routing van de berichten op basis van een XMPP-adres, en niet op basis van een IP-adres. Dit is veel voordeliger aangezien een XMPP-adres altijd overeenkomt met dezelfde persoon of toestel, terwijl een IP-adres vaak dynamisch toegekend wordt aan een toestel, en het actuele IP-adres dus eerst opgezocht moet worden. De tweede reden is dat men door XMPP te gebruiken ook automatisch de voordelen ervan overneemt: voornamelijk veiligheid en privacy, schaalbaarheid en een probleemloze omgang met NAT of firewalls (zie 2.2). De data getransporteerd door XMPP kan tekstuele data zijn, maar kan evengoed ook binaire of geserialiseerde data zijn, ingepakt in een XML-bericht.

76 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP XMPP voor RPC Het type informatie dat getransporteerd kan worden door XMPP is niet beperkt tot applicatie-data maar kan elk type informatie zijn dat reversibel omgezet kan worden naar data. Een voorbeeld met verregaande gevolgen is RPC (Remote Procedure Calls), of functie-oproepen. XML-RPC [127] specificeert een methode om functie-oproepen (methodenaam en parameters) en de antwoorden erop voor te stellen als XML-bestanden. Door deze bestanden te transporteren wordt het voor XMPP mogelijk om de communicatie tussen de verschillende componenten van een gedistribueerde applicatie te verzorgen. Hoe de XML-RPC bestanden concreet worden getransporteerd wordt vastgelegd door JEP-0009 [2] XMPP als transportprotocol voor SOAP XMPP hoeft niet enkel door applicaties als transportprotocol gebruikt te worden, maar kan ook als basis dienen voor andere protocollen, zoals bijvoorbeeld SOAP. SOAP (Simple Object Access Protocol) [34] is een licht protocol voor het uitwisselen van informatie in een gedecentraliseerde, gedistribueerde omgeving. Het maakt hiervoor gebruik van een speciaal type XML-bestanden: SOAP-berichten. SOAP specificeert echter enkel het formaat van de berichten, niet hoe ze getransporteerd worden. Dit laat SOAP over aan andere (transport)protocollen. Al wordt er in de specificaties [34] geen enkel transportprotocol opgelegd, toch wordt in het merendeel van de implementaties gebruik gemaakt van HTTP [27]. De reden hiervoor is eenvoudig: omdat de HTTP-poort van firewalls meestal open staat is het een manier om ervoor te zorgen dat de SOAP-berichten niet geblokkeerd worden. Het gebruik van HTTP heeft echter enkele nefaste gevolgen. Een eerste probleem is, dat door het beperkte aanvraag-antwoord model van HTTP, alleen synchrone communicatie mogelijk is. Er bestaan allerlei omslachtige methodes om dit te omzeilen, bijvoorbeeld door gebruik te maken van SMTP [76] om asynchrone berichten te transporteren (een doeleinde waarvoor SMTP helemaal niet geschikt is). Een ander probleem is dan weer dat de rollen

77 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 58 bij interacties vast staan: een partij kan gebruik maken van de diensten van een andere partij, maar niet vice-versa. Hierdoor kunnen de klassieke verwittigings-mechanismen niet gebruikt worden en moet de aanvrager actief pollen. Door XMPP te gebruiken als transportprotocol voor SOAP komen de bovenvermelde beperkingen van HTPP niet meer voor: XMPP is bidirectioneel en kan zowel synchrone als asynchrone berichten vervoeren. Bovendien worden niet alleen problemen met firewalls, maar ook met NAT vermeden. Omdat de adressering gebeurt op basis van XMPPadressen, zijn ingewikkelde protocollen als WS-Routing [70] en WS-Referral [69] ook niet meer nodig om entiteiten zonder publiek of statisch IP-adres te kunnen bereiken. De binding tussen XMPP en SOAP is gespecificeerd in hoofdstuk 4 van [28]. Er zijn nog vele andere synergetische combinaties mogelijk tussen XMPP en SOAP, en met Web Services in het algemeen. Zo kan bijvoorbeeld enerzijds van XMPP gebruik gemaakt worden om Web Services beschikbaar te maken aan IM-clients (zie [121]). Anderzijds voegt Jabber, Inc. Web Services-interfaces toe aan XMPP-diensten om de XMPP-middleware toegankelijk te maken voor applicaties [42] Besluit Zoals eerder gezegd is XMPP meer dan enkel een IM-protocol: het is een real-time transportprotocol voor informatie. Deze informatie kan applicatie-data zijn, zoals in toepassingen als IM, reageren op noodgevallen in een crisiscentra, netwerkbeheer, games, het uitwisselen van bestanden, VoIP, etc. Het begrip informatie kan echter veel ruimer geïnterpreteerd worden. XMPP kan in principe elk type informatie transporteren dat tekstueel of binair gerepresenteerd kan worden zoals bijvoorbeeld geserialiseerde objecten of RPC. Omdat XMPP tenslotte een technologie is om XML te streamen, is het bijzonder geschikt om XML data te transporteren. Twee reeds besproken voorbeelden hiervan zijn XML-RPC bestanden en SOAP-berichten, maar XMPP kan ook gebruikt worden als transportprotocol voor RSS (Really Simple Syndication) voor de syndicatie van informatie (zie ook

78 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 59 [12]), FIXML (Financial Information Exchangen Markup Language), etc. In de context van idtv zijn de mogelijkheden van XMPP nog interessanter, omdat men, door er gebruik van te maken, lichte implementaties kan bouwen van technologieën als RPC of SOAP. Bovendien kan XMPP voor een verbeterde gebruiksvriendelijkheid zorgen dankzij de probleemloze omgang met firewalls en NAT. XMPP kan via XML-RPC gebruikt worden om gedistribueerde applicaties te bouwen. 4. Gedistribueerde applicaties zijn bijzonder interessant voor idtv omdat ze toelaten om flexibel de last te verdelen tussen de STB en de server. Daardoor vervallen de beperkingen opgelegd door de beperkte resources van de STB en wordt het mogelijk om vrij zware toepassingen aan te bieden. Een extreem geval hiervan is om enkel de GUI (Grafical User Interface) op de STB te laten draaien, en de uitvoering van de rest van applicatie over te laten aan een server. Deze methode biedt nieuwe economische opportuniteiten. Dit kan goed geïllustreerd worden aan de hand van consolegames. Traditioneel gezien is er een console voor nodig en worden de inkomsten van een game gegenereerd door de verkoop ervan. In de plaats daarvan biedt men de game rechtstreeks aan op idtv en factureert men de spelers op de tijdsduur die ze gespeeld hebben. Dit business-model biedt vier bijkomende voordelen: voor de speler zijn de uitgaven verspreid in de tijd voor de producer zijn de inkomsten niet alleen verspreid in de tijd, maar kunnen ze bij populaire games ook significant hoger liggen; de grens om nieuwe games te proberen ligt lager omdat dit vrijblijvend is. Daarom moet er ook niet meer geïnvesteerd worden in het ontwikkelen van demo s. Omdat de games niet uitgevoerd kunnen worden zonder server, zijn ze ook beter beveiligd tegen piraterij. Andere voorbeelden van toepassingen die er baat bij kunnen hebben om XMPP te gebruiken voor interapplicatie-communicatie zijn bijvoorbeeld t-banking, EPG s, t-learning, 4 Afhankelijk van de vereisten kan men ook andere RPC-technologieën gebruiken zoals RMI of Corba.

79 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 60 etc. Om af te sluiten is het belangrijk om te vermelden dat het tekort aan QoS-garanties in gedachten gehouden moet worden bij de toepassing van XMPP voor één van bovenstaande doeleinden. In het volgende hoofdstuk bespreken hoe de XMPP-functionaliteiten kunnen toegevoegd worden aan applicaties Implementatiemogelijkheden In dit hoofdstuk worden twee verschillende aanpakken besproken om een applicatie XMPPenabled te maken a Een XMPP-library in de applicaties Bij deze optie, afgebeeld in figuur 3.5, zorgt elke applicatie die nood heeft aan XMPPfunctionaliteiten zelf voor de communicatie met het XMPP-netwerk. Een gemakkelijke manier om dit te doen is om bij het implementeren gebruik te maken van XMPP-library. Deze aanpak is vooral geschikt wanneer de kans dat er meerdere applicaties aanwezig zijn op de STB klein is. Zoniet is er redundantie: dezelfde functionaliteit is meermaals aanwezig. Dit kan een negatieve impact hebben op: de aanpasbaarheid en onderhoudbaarheid: wanneer een library wordt aangepast, moeten de veranderingen doorgevoerd worden in alle applicaties die de library bevatten; de prestaties: elk programma zal met het XMPP-netwerk communiceren via een verschillende XML-stream; de gebruiksvriendelijkheid: voor elke applicatie die wil inloggen op het XMPPnetwerk moet de gebruiker apart zijn account-gegevens opgeven.

80 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 61 Figuur 3.5: XMPP-enabled applicaties door middel van libraries b Een XMPP-middleware Wanneer meerdere applicaties XMPP-functionaliteiten nodig hebben is het interessanter om al deze functionaliteiten te verzamelen in één applicatie. Dit is de middleware-oplossing getoond in figuur 3.6: een software agent dient als tussenpersoon tussen de applicaties en het XMPP-netwerk. Bij deze aanpak moeten er twee kwesties opgelost worden. Ten eerste moet de middleware kunnen communiceren met de applicaties die er gebruik van willen maken. Voor deze doeleinde kan men de lokale versie van RMI gebruiken die MHP [26] ondersteunt. Het tweede probleem dat zich stelt is dat de middleware moet kunnen bepalen voor welke applicatie de ontvangen berichten bedoeld zijn. Dit zou opgelost kunnen worden door voor elke aplicatie een apart XMPP-adres of resource te gebruiken. Maar dan zou elke applicatie ook een eigen XMPP-stream hebben, met alle nadelen vandien (prestaties en gebruiksvriendelijkheid). Een geschiktere oplossing is om via een eigen extensie twee karaktersequenties in het bericht te integreren, die toelaten om de bron- en doelapplicatie

81 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 62 Figuur 3.6: XMPP-enabled applicaties door middel van een middleware. eenduidig te identificeren. 5 Door het gebruik van deze niet-gestandardiseerde extensie is interoperabiliteit met andere XMPP-middlewares uit den boze. Dit is echter sowieso niet mogelijk omdat er geen standaard voor bestaat. Wanneer voldoende applicaties gebruik maken van de middleware is deze aanpak interessanter omdat het netto resources-gebruik dan lager ligt, en bovendien moeten de XMLstreams maar één keer opgezet worden. Als slechts één applicatie er gebruik van maakt, is het beter om libraries te gebruiken omdat de communicatie tussen de applicatie en de XMPP-functionaliteiten dan veel sneller is (functie-oproepen i.p.v RMI). Een ander nadeel van de middleware-methode is dat het afhankelijkheden tussen applicaties introduceert (de applicaties kunnen enkel werken als de software agent aanwezig is). 5 Noteer dat deze oplossing veel gelijkenissen vertoont met het gebruik van poorten bij TCP of UDP.

82 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP c Plaats van de IM-client in de middleware Wanneer er voor een XMPP-middleware gekozen wordt zijn er twee mogelijke opties wat de IM-client betreft: de IM-client wordt beschouwd als een applicatie als elk ander en maakt ook gebruik van de middleware, zie figuur 3.7. Het voordeel hiervan is dat de IM-client dan volledig losgekoppeld is van het onderliggende IM-protocol, en evengoed kan werken met een andere middleware-implementatie van XMPP of een ander IM-protocol (met identieke interfaces). Deze oplossing is echter nadelig voor de prestaties van de IM-client omdat elke aanvraag naar de middleware via RMI verloopt. Het is echter ook mogelijk om de IM-client en de middleware te integreren in één applicatie, zie figuur 3.8. Conceptueel gezien is de middelware dan een IM-client die niet alleen berichten uitwisselt voor een gebruiker, maar ook voor applicaties. Er moet opgemerkt worden dat interapplicatie-communicatie heel andere vereisten oplegt dan klassieke IM (bv. een hogere bericht-rate). Om die reden kan het, afhankelijk van de context, af te raden zijn om een klassieke IM-client uit te breiden om andere toepassingen van XMPP te ondersteunen. Figuur 3.7: De IM-client als gebruiker van de middleware.

83 Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP 64 Figuur 3.8: De IM-client als onderdeel van de middleware.

84 Hoofdstuk 4 IM4MHP: een XMPP-client voor het MHP platform In hoofdstuk 1.5 werden de vereisten opgesteld van een IM-systeem voor idtv, om vervolgens in hoofdstuk 2 XMPP als kandidaat voor de implementatie naar voor te schuiven. Na een grondige vergelijking in 2.4 met andere implementatiemogelijkheden werd bevestigd dat deze oplossing het beste aan de vooropgestelde vereisten beantwoordt. In dit hoofdstuk wordt in detail ingegaan op de ontwikkelde IM-oplossing voor idtv, namelijk een XMPP-client voor het MHP platform: IM4MHP. In het eerste onderdeel van het hoofdstuk wordt de gekozen XMPP-library besproken om vervolgens in te gaan op de architectuur van de applicatie. Vervolgens komt de gebruikte testopstelling aan bod, gevolgd door een mapping tussen de karakteristieken van de applicatie en de vooropgestelde vereisten. Er worden ook enkele problemen opgesomd die ondervonden werden bij het ontwikkelen voor MHP. Uiteindelijk wordt IM4MHP vergeleken met een andere Instant Messenger voor idtv ontwikkeld door Alcatel, namelijk AmigoTV [16]. 4.1 De SMACK -library Bij het ontwikkelen van een XMPP-client kan men gebruik maken van een XMPP-library. Dit is interessant omdat hierdoor automatisch verschillende tactieken worden toegepast 65

85 Hoofdstuk 4. IM4MHP: een XMPP-client voor het MHP platform 66 die de aanpasbaarheid en onderhoudbaarheid van de applicatie verbeteren, namelijk: semantische coherentie, generalisatie van de aangeboden functionaliteit, het verbergen van informatie, een vaste interface en beperkte communicatiepaden (zie ook [5]). Omdat de library de technische details van XMPP verbergt, kan bovendien beter gefocust worden op andere aspecten van het implementeren. Omdat er (nog) geen XMPP-libraries beschikbaar zijn voor het MHP-platform heeft men twee opties: ofwel er één ontwikkelen of een bestaande library aanpassen. Omdat er kwaliteitsvolle libraries bestaan die slechts een geringe aanpassing vergen om compatibel te worden met MHP, wordt voor de tweede optie gekozen Verantwoording van de keuze Een overzicht van XMPP libraries is te vinden op [45]. Alleen libraries geschreven in Java komen in aanmerking omdat ze het gemakkelijkst aan te passen zijn door het feit dat ook MHP deze programmeertaal gebruikt. Hieraan voldoen acht client-libraries. Na een korte inspectie kunnen de volgende geschrapt worden: JabberBeans: bestaat niet meer; JSO: enkel een laagniveau ondersteuning voor elementen van het XMPP -protocol; Micro-jabber: enkel voor J2ME (Java 2 Micro Edition) 1 ; Tweeze: voorziet enkel een implementatie van XMPP-core [87], niet XMPP-IM [88]. De vier overigen hebben allemaal een licentie die aanpassingen toelaat. Het overzicht in tabel 4.1 vat enkele karakteristieken samen. Uit dit overzicht blijkt dat de twee meest uitgebreide en best gedocumenteerde libraries Echomine Muse en Smack [111] zijn. Alle bovenvermelde libraries zijn zelf ook afhankelijk van een aantal libraries. Dit is in deze context van groot belang omdat deze libraries niet beschikbaar zijn op MHP en dus ook aangepast moeten worden. Dit is een bijkomend voordeel voor SMACK: het is slechts 1 Omdat MHP vanaf versie gebaseerd is op J2ME wordt de karakteristiek van Micro-jabber ook opgenomen in tabel 4.1.

86 Hoofdstuk 4. IM4MHP: een XMPP-client voor het MHP platform 67 Naam Licentie # klassen # afhankelijkheden # extensies doc Echomine Muse Apache JabberWookie BSD 34 3 in Smack Apache Yaja LGPL Micro-jabber LGPL Tabel 4.1: Enkele karakteristieken van XMPP-client libraries afhankelijk van één lichte XML-parsing library die reeds compatibel is met MHP. Daarbovenop ligt het niveau van abstractie van SMACK hoger dan in Echomine Muse waardoor het ook gemakkelijker in gebruik is. Deze bijkomende argumenten leggen de keuze definitief vast Aanpassen van de library aan MHP De incompatibiliteiten tussen MHP en de SMACK-library zijn een gevolg van het feit dat MHP slechts een deel van de klassen van het Java Platform 1.1 ondersteunt. De meeste niet ondersteunde klassen waar SMACK gebruik van maakt, kunnen vervangen worden door gelijkaardige klassen die wel onderdeel zijn van MHP: alle implementaties van java.util.map, zoals bijvoorbeeld java.util.hashmap, door de klasse java.util.hashtable die dezelfde rol speelt maar gesynchroniseerd is; alle implementaties van java.util.list, zoals bijvoorbeeld java.util.arraylist, door de klasse java.util.vector die ook de rol van een lijst met variërende grootte speelt maar gesynchroniseerd is; java.util.iterator door de oudere versie java.util.enumeration. SMACK gebruikt echter ook mechanismen die door MHP niet ondersteund worden waardoor problemen ontstaan die veel ingewikkelder zijn om op te lossen: SMACK maakt bij sommige extensies gebruik van introspectie 2 om de pakketten te kunnen parsen. Dit mechanisme wordt echter niet ondersteund door MHP en is 2 Introspectie maakt gebruik van het reflectie-mechanisme om dynamisch de eigenschappen van een object op te vragen en te wijzigen en wordt voornamelijk gebruikt voor Java-Beans.

87 Hoofdstuk 4. IM4MHP: een XMPP-client voor het MHP platform 68 daarom vervangen door reflectie 3 (zie de methode parsewithintrospection() van de klasse PacketParserUtils); Weak References zijn losse verwijzingen naar objecten die, in tegenstelling tot gewone referenties, niet beletten dat de objecten uit het geheugen worden verwijderd. Omdat MHP dit mechanisme niet ondersteunt is de enige oplossing echte referenties te gebruiken. Deze moeten dan na gebruik expliciet verwijderd worden om geen geheugenlekken te veroorzaken. Andere maatregelen die ook genomen zijn door het tekort aan ondersteuning door MHP zijn de volgende: de (verouderde) ondersteuning voor SSL-encryptie is verwijderd; het opladen van configuratiegegevens gebeurt niet meer dynamisch: de gegevens zijn hard-gecodeerd (zie bv. de lijst van providers in de klasse ProviderManager); de VCard-extensie is verwijderd. Een nadeel van SMACK is dat de uitgewisselde data steeds geëncrypteerd is met TLS. Het is echter interessant om deze functionaliteit te kunnen uitschakelen. Dit is in de aangepaste versie mogelijk aan de hand van de variabele ENCRYPT_COMM in de klasse org.jivesoftware.smack.xmppconnection Gebruik van de SMACK API Voor de ontwikkelaar heeft de SMACK API twee voordelen: het is eenvoudig om te gebruiken en het laat zowel hoog- als laagniveau handelingen toe op de pakketten. Dit wordt geïllustreerd aan de hand van de volgende voorbeelden: een verbinding maken met een server (in het voorbeeld jabber.org) en de bidirectionele XMPP-streams opzetten zodat er stanzas uitgewisseld kunnen worden: XMPPConnection connection = new XMPPConnection( jabber.org ); 3 Reflectie is een mechanisme dat toelaat om dynamisch de geschikte methode van een object te selecteren en uit te voeren.

88 Hoofdstuk 4. IM4MHP: een XMPP-client voor het MHP platform 69 een nieuw account maken bij de server waarmee men reeds verbonden is: connection. getaccountmanager().createaccount( kevinh, paswoord ); inloggen op de server waarmee men reeds verbonden is: connection.login( kevinh, paswoord, TV ); een bericht aanmaken en versturen: Message bericht = new Message(); bericht.setbody( inhoud... ); bericht.setsubject( titel... ); bericht.setto( kevin@hoekman.be ); connection.sendpacket(bericht); SMACK laat toe om zowel synchroon als asynchroon te wachten op de ontvangst van pakketten. Bij de synchrone werkwijze wordt de uitvoeringsdraad stilgelegd tot een pakket ontvangen wordt. Dit is bijvoorbeeld handig als er gewacht moet worden op een antwoord op een verstuurd pakket. Hiervoor biedt SMACK de klasse org.jivesoftware.smack.packetcollector aan. Bij de asynchrone werkwijze loopt de uitvoeringsdraad verder en wordt er een methode gespecificeerd die moet worden uitgevoerd bij ontvangst van een pakket. Hiervoor kan men de klasse org.jivesoftware.smack.packetlistener gebruiken. Omdat de ontvangen pakketten hierbij verwerkt worden in een aparte uitvoeringsdraad moet men wel opletten voor synchronisatiefouten. Een functionaliteit specifiek aan SMACK is eigenschappen kunnen toevoegen aan pakketten. Deze eigenschappen worden gekarakteriseerd door een naam en door een waarde. Deze waarde kan zowel een object als een primitief datatype van Java kan zijn. SMACK doet dit aan de hand van een eigen extensie zodat de eigenschappen alleen gelezen kunnen worden door de SMACK-library.

89 Hoofdstuk 4. IM4MHP: een XMPP-client voor het MHP platform XML-parsing Door de beperkte resources van een STB kan de keuze van een XML-parser een belangrijke invloed hebben op de prestaties van de applicatie (zie 2.3.1). Om een juiste keuze te maken is het belangrijk de verschillende types parsers te onderscheiden. Een eerste onderscheid kan gemaakt worden tussen validerende en niet-validerende parsers. Validerende parsers kijken de geldigheid van het geparste XML-document na, wat betekent dat het voldoet aan een welbepaald schema. Omdat XMPP geen gebruik maakt van deze functionaliteit is een validerende XML-parser niet nodig. Een tweede onderscheid kan gemaakt worden op basis van de verwerking van het document. Langs de ene kant zijn er één-staps parsers, die het XML-document in één keer verwerken, langs de andere kant zijn er incrementele parsers die het document onderdeel per onderdeel verwerken. Eén-staps parsers zijn voor XMPP onbruikbaar omdat het volledige XML-document al aanwezig moet zijn en dit bij XMPP pas het geval is wanneer de stream terug gesloten wordt. Bovendien zijn dit soort parsers niet interessant voor idtv omdat ze bij grote documenten veel geheugen vergen. Een laatste onderscheid is de manier waarop de parser de informatie naar het gebruikend programma stuurt. De twee basis parsing-interfaces zijn de DOM- en de SAX-interface. Bij DOM (Document Object Model) bouwt een één-staps parser in het geheugen een boom op van het document, waarna de applicatie willekeurig informatie kan opvragen uit de boom. Deze methode is niet alleen trager maar ook onbruikbaar omdat het gebruik maakt van een één-staps parser. De SAX-interface gebruikt een incrementele parser en genereert events voor elk verwerkt onderdeel van het document. De gebruikende applicatie kan deze events opvangen door een event handler op te geven aan de parser, die dan bepaalt wat er moet gebeuren wanneer events ontvangen worden (callback-mechanisme). Deze interface werkt dus volgens een push-mechanisme: de parser duwt de informatie naar de applicatie. Een recenter type interface is pull-parsing [110], ook de Streaming-API [79] genoemd. De gebruikende applicatie kan bij deze methode de geparste onderdelen opvragen ( trekt de informatie uit de parser) waardoor een meer procedurale aanpak mogelijk wordt. Daardoor

90 Hoofdstuk 4. IM4MHP: een XMPP-client voor het MHP platform 71 is deze interface gemakkelijker om te gebruiken dan de event-gebaseerde SAX-interface. Bovendien zijn de prestaties voor het parsen van kleine en middelgrote documenten in het algemeen ook beter dan bij SAX en DOM [112]. Het is dan ook van dit type parser dat SMACK gebruik maakt. 4.2 Overzicht van IM4MHP In dit hoofdstuk wordt de ontwikkelde XMPP-client IM4MHP besproken. Eerst wordt er ingegaan op de architectuur van de applicatie. Vervolgens wordt er ingegaan op enkele kleinere onderwerpen zoals de gebruikte methodes om de invoer van de gebruiker te ontvangen en de implementatie van de tv-specifieke functionaliteiten. Uiteindelijk wordt de externe code toegelicht en enkele uitbreidingen op de applicaties worden voorgesteld. Er moet worden vermeld dat bij het ontwikkelen van deze applicatie de nadruk niet lag op gebruiksvriendelijkheid Architectuur De architectuur van IM4MHP is eenvoudig en bestaat, zoals gerepresenteerd in figuur 4.1, uit drie verschillende lagen. Figuur 4.1: De verschillende lagen van IM4MHP. De SMACK-library werd reeds in het vorige hoofdstuk besproken. Er wordt nu ingegaan op de twee andere lagen van de applicatie: de grafische laag en de logische laag.

91 Hoofdstuk 4. IM4MHP: een XMPP-client voor het MHP platform a De grafische laag De grafische laag is verantwoordelijk voor de interactie met de gebruiker. Dit bestaat uit twee taken: het opbouwen en tonen van de GUI enerzijds, de invoer van de gebruiker ontvangen en verwerken anderzijds. Zoals getoond in figuur 4.2 bestaat de grafische laag uit drie verschillende types klassen: WindowProfiles, HardwareManagers en Windows, en uit de klasse WindowManager. Figuur 4.2: De verschillende packages van de grafische laag. Window manager De klasse WindowManager heeft, door het gebruik van de singleton design-pattern, maximaal één instantie. Deze klasse, gerepresenteerd in figuur 4.3, laat toe om een windowprofile in te stellen of om de huidige windowprofile op te vragen.