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

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 2005–2006

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.

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

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

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 2005–2006 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

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

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. I NTRODUCTION 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 (email-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, email, ...). 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

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. A DDING 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. 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

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. C ONCLUSION 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. R EFERENCES [1]

[2] [3]

[4] [5] [6] [7] [8] [9] [10] [11] [12] [13]

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. 99–107. European Telecommunications Standards Institute (ETSI), Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3, 2003. 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. 199–208. P. Saint-Andre, “Extensible Messaging and Presence Protocol (XMPP): Core, RFC 3920,” 2004. P. Saint-Andre, “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, RFC 3921,” 2004. I. Shigeoka, Instant Messaging in Java: The Jabber Protocols, Manning Publications, 2002. The Jabber Software Foundation (JSF), “Jabber :: JEPs. http: //www.jabber.org/jeps/, gelezen op 20/05/2006,” 2006. SMACK API, “Smack API: Simple and Powerful Java client API for XMPP. http://www.jivesoftware. org/smack/, gelezen op 20/05/2006,” 2006. T. Muldowney, M. Miller, and R. Eatmon, “Jep-0096: File Transfer,” 2004. J. Hildebrand, P. Millard, R. Eatmon, and P. Saint-Andre, “Jep0030: Service Discovery,” 2006. J. Karneges, “Jep-0047: In-Band Bytestreams (IBB),” 2003. D.J. Adams, “Jep-0009: Jabber-RPC,” 2006. F. Forno and P. Saint-Andre, “Jep-0072: SOAP Over XMPP,” 2005.

Inhoudsopgave

1 Situering 1.1

1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.2

Het Multimedia Home Platform . . . . . . . . . . . . . . . . . . . .

2

1.2

Instant Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Waarom een Instant Messenger voor interactieve televisie? . . . . . . . . .

4

1.4

Het verschil tussen de computer en iDTV . . . . . . . . . . . . . . . . . . .

6

1.4.1

Verschillen in hardware . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.4.2

Verschillen in scherm . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.4.3

Verschil in publiek en perceptie . . . . . . . . . . . . . . . . . . . .

8

De vereisten van een IM-applicatie voor iDTV . . . . . . . . . . . . . . . .

9

1.5

1.6

Digitale televisie

1.5.1

Functionele vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5.2

Kwaliteitsvereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Implementatiekeuze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 XMPP/Jabber 2.1

13

XMPP: werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.1

De netwerkarchitectuur . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.2

XMPP adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

i

Inhoudsopgave

ii

2.1.3

XML-streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.4

XML-stanzas en de kernprotocollen van XMPP . . . . . . . . . . . 16 2.1.4 I a de <message/> stanza: het berichtgevingsprotocol . . . . 16 2.1.4 I b de <presence/> stanza: het presence-protocol . . . . . . . 18 2.1.4 I c de stanza: het ‘overige’ protocol . . . . . . . . . . . 20

2.2

2.3

2.4

2.5

Voordelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.1

Voldoet aan de vereisten . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.2

Lightweight clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.3

Veiligheid en Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.4

Een open internet standaard gebaseerd op XML . . . . . . . . . . . 27

2.2.5

Extra functionele- en kwaliteitsattributen . . . . . . . . . . . . . . . 28

2.2.6

Quality of service and policy . . . . . . . . . . . . . . . . . . . . . . 28

2.2.7

Uitbreidbaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2.8

Bestaande software . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Nadelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.1

XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3.2

Rechtstreekse communicatie tussen clients . . . . . . . . . . . . . . 31

2.3.3

Quality of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.4

Maturiteit van het protocol en extensies . . . . . . . . . . . . . . . 34

XMPP versus andere technologieën . . . . . . . . . . . . . . . . . . . . . . 36 2.4.1

Peer-to-peer (P2P) en JXTA . . . . . . . . . . . . . . . . . . . . . . 36

2.4.2

SIP en SIMPLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.4.3

RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.4.4

Gesloten protocollen . . . . . . . . . . . . . . . . . . . . . . . . . . 44

De toekomst van XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Inhoudsopgave

iii

3 Andere toepassingsmogelijkheden van XMPP 3.1

47

Flexibel diensten toevoegen door middel van chatbots . . . . . . . . . . . . 48 3.1.1

Voordelen van chatbots . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.1.2

Voorbeelden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.1.2 I a Voorbeeld 1: Deelnemen aan een tv-kwis . . . . . . . . . . 49 3.1.2 I b Voorbeeld 2: Gebruikersondersteuning . . . . . . . . . . . 51 3.1.2 I c Voorbeeld 3: Een tekst-gebaseerde email-client . . . . . . . 51 3.1.2 I d Voorbeeld 4: Informatie opvragen . . . . . . . . . . . . . . 52 3.1.2 I e Voorbeeld 5: Impulsaankopen . . . . . . . . . . . . . . . . 53

3.2

3.1.3

Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.1.4

Beperkingen van chatbots . . . . . . . . . . . . . . . . . . . . . . . 54

Interapplicatie-communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.2.1

XMPP als generisch datatransportprotocol . . . . . . . . . . . . . . 55

3.2.2

XMPP voor RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.2.3

XMPP als transportprotocol voor SOAP . . . . . . . . . . . . . . . 57

3.2.4

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.2.5

Implementatiemogelijkheden . . . . . . . . . . . . . . . . . . . . . . 60 3.2.5 I a Een XMPP-library in de applicaties . . . . . . . . . . . . 60 3.2.5 I b Een XMPP-middleware . . . . . . . . . . . . . . . . . . . 61 3.2.5 I c Plaats van de IM-client in de middleware . . . . . . . . . . 63

4 IM4MHP: een XMPP-client voor het MHP platform 4.1

65

De SMACK -library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.1.1

Verantwoording van de keuze . . . . . . . . . . . . . . . . . . . . . 66

4.1.2

Aanpassen van de library aan MHP . . . . . . . . . . . . . . . . . . 67

4.1.3

Gebruik van de SMACK API . . . . . . . . . . . . . . . . . . . . . 68

Inhoudsopgave

4.1.4 4.2

iv

XML-parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Overzicht van IM4MHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.2.1

Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.2.1 I a De grafische laag . . . . . . . . . . . . . . . . . . . . . . . 72 4.2.1 I b De logica-laag . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.2.1 I c De interactie tussen de grafische en de logica-laag . . . . . 78

4.2.2

Verloop van de uitvoeringsdraden . . . . . . . . . . . . . . . . . . . 78

4.2.3

Input van de gebruiker . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.2.4

Implementatie van tv-specifieke functionaliteiten . . . . . . . . . . . 80

4.2.5

Externe code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.2.6

Mogelijke uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.3

De testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.4

Vervulling van de vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.5

Problemen bij het implementeren voor MHP . . . . . . . . . . . . . . . . . 84

4.6

Verschil tussen IM4MHP en AmigoTV . . . . . . . . . . . . . . . . . . . . 84

5 Besluit en toekomstperspectieven

86

Appendix A: Inhoud van de CD-ROM

88

Lijst van afkortingen AI

Artificiële intelligentie

AIM

AOL Instant Messenger

A.L.I.C.E.

Artificial Linguistic Internet Computer Entity

API

Application program interface

ASCII

American Standard Code for Information Interchange

CPU

Central processing unit

DOM

Document Object Model

DTMF

Dual Tone Multi-Frequency

DVB

Digital Video Broadcasting

DVB-J

DVB-Java

EPG

Electronic Program Guide

ETSI

European Telecommunications Standards Institute

FIXML

Financial Information Exchange Markup Language

GSM

Global System for Mobile Communications

GUI

Graphical user interface

HAVi

Home Audio Video Interoperability

HD

Hard disk of hard drive

HTML

HyperText Markup Language

HTTP

Hypertext Transfer Protocol

IAX

Inter-Asterisk eXchange

ICE

Interactive Connectivity Establishment

iDTV

Interactive Digital Television

IETF

Internet Engineering Task Force

v

Lijst van afkortingen

vi

IM

Instant messaging of instant messenger

IQ

Info-query

IRC

Internet Relay Chat

IRT

Institut für Rundfunktechnik

iTV

Interactive Television

J2ME

Java 2 Micro Edition

JEP

Jabber Enhancement Proposal

JID

Jabber ID

JSF

Jabber Software Foundation

JXTA

Juxtapose

LGPL

GNU Lesser General Public License

MHP

Multimedia Home Platform

MPEG

Moving Picture Experts Group

MSN

Microsoft Network

NAT

Network address translation

NTSC

National Television System(s) Committee

OCAP

Open Cable Application Platform

OS

Operating system

PAL

Phase-alternating line

pc

Personal computer

PDA

Personal digital assistants

PHP

PHP Hypertext Preprocessor of Personal Home Page Tools

PINE

Program for Internet News & Email

QoS

Quality of Service

RAM

random access memory

RC

Return Channel

RFC

Requests for Comment

RMI

Remote Method Invocation

RTP

Real-time Transport Protocol

Lijst van afkortingen

vii

SASL

Simple Authentication and Security Layer

SAX

Simple API for XML

SIMPLE

SIP for Instant Messaging and Presence Leveraging Extensions

SIP

Session Initiation Protocol

SMS

Short message service

SOAP

Simple Object Access Protocol

STB

Set-top box

STUN

Simple Traversal of UDP over NATs

Tcl

Tool Command Language

TCP

Transmission Control Protocol

TLS

Transport Layer Security

tv

Televisie

TVPR

Tv-program recommendation

UDP

User Datagram Protocol

VOD

Video on demand

VOiP

Voice over IP

XHTML

Extensible HyperText Markup Language

XML

Extensible Markup Language

XMPP

Extensible Messaging and Presence Protocol

Lĳst van figuren

1.1

Representatie van de MHP-softwarestack (Bron: Wikipedia) . . . . . . . .

2

2.1

Illustratie van de reisweg van een XMPP bericht. . . . . . . . . . . . . . . 14

2.2

Reisweg van een XMPP bericht door de XML-streams naar een lokale (a) en niet-lokale gebruiker (b). . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3

Toestandsdiagramma van de inschrijving op een roster. . . . . . . . . . . . 20

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. . . . . . . . . . . . . . . . 46

3.1

Interactie tussen de deelnemers en de chatbot tijdens een tv-kwis. . . . . . 50

3.2

Probleem om de verzendtijd van het antwoord te bepalen. . . . . . . . . . 50

3.3

Uitwisseling van informatie bij het gebruik van een email-chatbot. . . . . . 52

3.4

Datatransport tussen twee applicaties door gebruik te maken van het XMPPprotocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.5

XMPP-enabled applicaties door middel van libraries. . . . . . . . . . . . . 61

3.6

XMPP-enabled applicaties door middel van een middleware. . . . . . . . . 62

3.7

De IM-client als gebruiker van de middleware. . . . . . . . . . . . . . . . . 63

3.8

De IM-client als onderdeel van de middleware. . . . . . . . . . . . . . . . . 64

4.1

De verschillende lagen van IM4MHP. . . . . . . . . . . . . . . . . . . . . . 71

viii

Lĳst van figuren

ix

4.2

De verschillende packages van de grafische laag. . . . . . . . . . . . . . . . 72

4.3

De klasse WindowManager. . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.4

Een klasse-diagram van de windowprofiles. . . . . . . . . . . . . . . . . . . 73

4.5

Een voorbeeld van de startup windowprofile. . . . . . . . . . . . . . . . . . 74

4.6

Opbouw van de minimized windowprofile. . . . . . . . . . . . . . . . . . . 75

4.7

Opbouw van de maximized windowprofile. . . . . . . . . . . . . . . . . . . 76

4.8

Een klasse-diagram van de Windows. . . . . . . . . . . . . . . . . . . . . . 76

4.9

Een klasse-diagram van de hardwaremanagers. . . . . . . . . . . . . . . . . 77

4.10 Een voorstelling van de testopstelling. . . . . . . . . . . . . . . . . . . . . . 82

Lĳst van tabellen

1.1

Vergelijking van de rekenkracht en het geheugen tussen een paar STB’s en een modale pc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1

Vergelijking van de functionaliteiten beschikbaar in XMPP en SIP/SIMPLE 39

2.2

Aantal gebruikers van enkele populaire IM-diensten. Bron: [124]. . . . . . . 45

4.1

Enkele karakteristieken van XMPP-client libraries . . . . . . . . . . . . . . 67

x

Hoofdstuk 1 Situering 1.1 1.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 40.000 abonnees [19] en verkocht het nog voor eind januari 2006 de 100.000ste digibox [49]. De concurrent Belgacom TV had eind 2005 33.000 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 beelden 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

Hoofdstuk 1. Situering

2

de zogenaamde ’killertoepassingen’, waaronder Instant Messaging (IM), zullen bepalend zijn voor het toekomstige succes van iDTV.

1.1.2

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 1.0.3 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 DVBJ (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


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 e-mail 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.


1.3

4

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. 2003 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


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.


1.4 1.4.1

6

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.

CPU (MHz) RAM (MB) Flash (MB) HD (GB)

1.4.2

ADB Q.75 STB 166 72 16 -

Telenet Digibox (DB-AD101) 166 48 24 -

Telenet Digicorder (DC-AD1000) 243 64 20 160

Modale pc 3000 1024 250

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


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


8

toestel tot toestel.

1.4.3

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


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 Pharming1 . 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...

1.5

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


1.5.1

10

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.


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.

1.5.2

Kwaliteitsvereisten

Prestatie is een belangrijk aspect van een IM-systeem door het real-time karakter ervan. In tegenstelling tot email 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.


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.

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 2000. 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

Hoofdstuk 2. XMPP/Jabber

2.1 2.1.1

14

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 email (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 [email protected] naar [email protected]. [email protected] 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 [email protected] (3).

Figuur 2.1: Illustratie van de reisweg van een XMPP bericht.

2.1.2

XMPP adressen

In XMPP is elke netwerk-entiteit1 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.


15

een domain identifier, een node identifier en een resource identifier. Het wordt geschreven als <node identifier>@<domain 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. [email protected]). Een gebruiker kan meerdere resource identifiers hebben die elk een ander netwerkeindpunt vertegenwoordigen. We komen terug op de rol van resources in 2.2.5. 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 @/.

2.1.3

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 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-stanzas2 . 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


16

xmlns:stream=‘http://etherx.jabber.org/streams’ 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=‘http://etherx.jabber.org/streams’ from=‘jabber.com’ id=‘D935000041D3’ 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).

2.1.4

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 stanza.

2.1.4 I 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.


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.


18

Men kan het type van het bericht opgeven door het attribuut type één van de opgesomde waarden te geven. De waarde van het element van een bericht verstuurd in het kader van een converatie, identificeert eenduidig de conversatie waartoe het bericht behoort.

2.1.4 I 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 [email protected] is de volgende:


19

<presence from=‘[email protected]/pc’> <status>Ik ben in een vergadering <priority>10 <show>dnd Op de betekenis van het subelement <priority/> komen we in 2.2.5 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 [email protected]: <presence to=‘[email protected]’ 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.


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=‘[email protected]’ to=‘[email protected]’> <error type=‘cancel’>

2.1.4 I c

de 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).


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 2.1.4 I 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:


22

• een kopie van de roster opvragen (bijvoorbeeld bij het inloggen). De volgende stanza is daar een voorbeeld van: Een mogelijk antwoord van de server is dan: Friends Friends • een roster item toevoegen of aanpassen: Friends

De server antwoordt hierop: en stuurt de veranderingen door naar alle resources van de gebruiker die een kopie


23

van de roster hebben opgevraagd (bv. [email protected]/TV en [email protected]/pc): Friends en Friends

Elke resource die deze stanza ontvangt moet hierop reageren met een IQ-stanza van het type ‘result’ of ‘error ’. Bv.: en • een roster item verwijderen:


24

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 2.2.1. Daarnaast bevat het ook bijzondere karakteristieken die het extra geschikt maken voor iDTV. Deze worden besproken in de twee volgende paragrafen. Vanaf paragraaf 2.2.4 worden de andere voordelen van XMPP die minder specifiek zijn voor iDTV bekeken.

2.2.1

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.


25

Er bestaan niet alleen transporten naar andere IM-diensten maar ook naar andere diensten zoals SMS of email. Figuur 2.4 illustreert de werking van een transport. Voor meer informatie zie [106].

2.2.2

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.


2.2.3

26

Veiligheid en Privacy

Zoals besproken in 1.4.3 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, @<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 @<server>/


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.

2.2.4

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 (www.w3c.org) 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.


2.2.5

28

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 (kevin@hoekman/TV is bv. de resource met naam TV van het account [email protected]). 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 2.1.4 I 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.

2.2.6

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


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.

2.2.7

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 XHTML3 . Een voorbeeldstanza die deze extensie bevat is de volgende: <message from=‘[email protected]/TV’ to=‘[email protected]’> Dit is een groene vet-gedrukte tekst! 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.


30

<span style=‘color:green;font-weight:bold’> Dit is een groene vet-gedrukte tekst!

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.

2.2.8

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, J2ME4 , 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 4.1.1 vergelijken we enkele bestaande libraries. 4

Java 2 Micro Edition


2.3 2.3.1

31

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 voorkomen5 . De keuze van een XML-parser wordt besproken in 4.1.4.

2.3.2

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.


32

van de extensie JEP-00966 [66] die zich meer specifiek toespitst op het uitwisselen van bestanden.

2.3.3

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].


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 uitbreiden7 . 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.


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.

2.3.4

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.


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 2.2.7. 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 standaard8 . De toepassingsmogelijkheden van XMPP zijn echter zo ruim dat men niet 8

MPEG 7 is een voorbeeld van standaard dat opgedeeld is in profiles.


36

voor deze oplossing kan kiezen zonder aan eenvoud en flexibiliteit in te boeten.

2.4

XMPP versus andere technologieën

2.4.1

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


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, platformen 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].

2.4.2

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


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. 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. 10


Basis functionaliteiten Presence Single Messages Chat Messages Buddy-list Service Discovery Geavanceerde functionaliteiten Communications Blocking Composing Indicators Capabilities Advertisement File transfer Service Registration Multi-User Chat Formatted Messages (XHTML) Offline Messages

39

XMPP SIP/SIMPLE Standard Standard [80] Standard Standard [11] Standard Experimental [10] Standard Experimental [81] Standard Extension [36] Draft [84] XMPP Standard Draft [105] Draft [37] Draft [66] Standard [96] Draft [91] Draft [95] Draft [99]

SIP/SIMPLE Unsupported Draft [107] Experimental [52] [31] Unsupported Unsupported Unsupported 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 protocollen11 en daarom ook plaatsen bandbreedte-inefficiënt. Bij SIP is dit echter erger dan bij XMPP: de minimum grootte12 van een SIMPLE bericht is al gauw 260 bytes in vergelijking met 100 bytes 11 12

De syntax van SIP is grotendeels gebaseerd op die van het HTTP-protocol. Deze getallen moet met de nodige omzichtigheid geïnterpreteerd worden en zijn niet volledig onpar-


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 2.4.1 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.


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-bound13 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.


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 beide14 . 2. 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.


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.

2.4.3

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].


2.4.4

44

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 is15 , is de enige manier om het te ontcijferen meestal reverse engineering16 , 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 (13.500.000 gebruikers) 15 16

Microsoft heeft het MSN Messenger Service 1.0 Protocol echter wel bekend gemaakt, zie [65]. Zie [61] om de methodologie voor gesloten protocollen te achterhalen.


45

en in mindere mate op de recreatieve markt (7.500.000 gebruikers). Het feit dat Google Talk XMPP ondersteunt zou daar snel verandering in kunnen brengen. IM-dienst AIM MSN Messenger Skype Yahoo! Messenger ICQ Jabber/XMPP QQ Gadu-Gadu

# actieve gebruikers totaal # gebruikers 53.000.000 (aug. 2005) 195.000.000 (jan. 2003) 29.000.000 (aug. 2005) 155.000.000 (apr. 2005) 45.000.000 (sept. 2005) 21.000.000 (sept. 2005) 15.000.000 400.000.000 21.000.000 10.000.000 400.000.000 (2005) 3.600.000

Tabel 2.2: Aantal gebruikers van enkele populaire IM-diensten. Bron: [124].

Zoals besproken in 2.4.2 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].


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.

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 zijn1 , 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 2.4.3

47

Hoofdstuk 3. Andere toepassingsmogelijkheden van XMPP

3.1

48

Flexibel diensten toevoegen door middel van chatbots

3.1.1

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


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.

3.1.2

Voorbeelden

3.1.2 I 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.


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.


51

We komen in 3.1.4 op deze problemen terug.

3.1.2 I 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.

3.1.2 I c

Voorbeeld 3: Een tekst-gebaseerde email-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 3.1.4. In dit voorbeeld wordt voor een email-client gekozen. De manier waarop de gebruiker omgaat met de applicatie is identiek aan die bij andere tekst-gebaseerde emailprogramma’s


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 email-chatbot.

3.1.2 I 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


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.

3.1.2 I 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.

3.1.3

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.


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 3.1.2 I 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.

3.1.4

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


55

chatbots. Een goed voorbeeld hiervan zijn de problemen die optreden bij de werking van de tv-kwis besproken in 3.1.2 I 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 3.1.1 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.

3.2.1

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.


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.


3.2.2

57

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].

3.2.3

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


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].

3.2.4

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


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.


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.

3.2.5

Implementatiemogelijkheden

In dit hoofdstuk worden twee verschillende aanpakken besproken om een applicatie XMPPenabled te maken.

3.2.5 I 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.


61

Figuur 3.5: XMPP-enabled applicaties door middel van libraries.

3.2.5 I 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


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.


3.2.5 I c

63

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.


Figuur 3.8: De IM-client als onderdeel van de middleware.

64

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

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.

4.1.1

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 1.1.2 gebaseerd is op J2ME wordt de karakteristiek van Micro-jabber ook opgenomen in tabel 4.1.


67

Naam Licentie # klassen # afhankelijkheden # extensies doc Echomine Muse Apache 135 4 22 +++ JabberWookie BSD 34 3 in 1 0 Smack Apache 163 1 9 +++ Yaja LGPL 49 5 0 Micro-jabber LGPL 32 0 0 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.

4.1.2

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 introspectie2 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.


68

daarom vervangen door reflectie3 (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.

4.1.3

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.


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(“[email protected]”); 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.


4.1.4

70

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


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.

4.2.1

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.


4.2.1 I a

72

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.


73

Figuur 4.3: De klasse WindowManager.

Windowprofiles Windowprofiles specificeren een bepaalde manier om windows op het scherm te tonen en geven dus elk een andere representatie van het programma. De window manager garandeert dat er op elk ogenblik van de uitvoering maar één windowprofile actief kan zijn. Alle windowprofiles erven van een abstracte klasse WindowProfile zodat men naar de actuele windowprofile kan verwijzen zonder zijn type te kennen (Mediator -pattern). Dit wordt geïllustreerd in figuur 4.4. Dit flexibele mechanisme laat toe om gemakkelijk nieuwe representaties toe te voegen aan de applicatie zonder verdere aanpassingen in het programma te moeten maken (met uitzondering van de WindowManager).

Figuur 4.4: Een klasse-diagram van de windowprofiles.


74

De vier verschillende windowprofiles die reeds aanwezig zijn worden nu kort besproken. • de startup windowprofile: deze profile toont één venster op het scherm, bovenop de onaangeroerde video-laag. Het wordt gebruikt bij het opstarten van de applicatie om de verschillende windows te tonen die toelaten om in te loggen en een nieuwe account aan te maken. Een voorbeeld wordt getoond in figuur 4.5

Figuur 4.5: Een voorbeeld van de startup windowprofile.

• de minimized windowprofile is een compromis tussen de applicatie gebruiken en naar tv kijken. De video-laag wordt verkleind en in de rechterbovenhoek weergegeven. Er zijn drie plaatsen voorzien voor windows: linksboven voor de FunctionalityLegendWindow, links voor ofwel de RosterWindow, ofwel de OverviewWindow, en vanonder voor elk andere window. Dit wordt geïllustreerd in figuur 4.6.


75

Figuur 4.6: Opbouw van de minimized windowprofile.

• de maximized windowprofile is optimaal voor het gebruiken van de applicatie. Zoals afgebeeld in figuur 4.7 is de video-laag niet meer zichtbaar en neemt de applicatie het volledige scherm in beslag. De OverviewWindow en RosterWindow worden simultaan getoond en de overige windows kunnen getoond worden op een groter oppervlak. • de invisible windowprofile laat toe om ongestoord naar tv te kijken terwijl de applicatie nog actief is. Bij het drukken op een toets verschijnt een window die uitlegt hoe over te schakelen naar een ander profiel. Windows Windows zijn klasses verantwoordelijk voor het opbouwen van een bepaalde component en voor het verwerken van de invoer die deze component krijgt. Windowprofiles kunnen de te tonen component uit een venster halen door middel van de methode getWindow() en de gewenste grootte van de component als argument mee te geven. Omdat de focusaanvraag pas kan gebeuren nadat de component op het scherm getoond is, is er een methode getFocusObject() nodig om te bepalen welk onderdeel van de component de


76

Figuur 4.7: Opbouw van de maximized windowprofile.

focus moet krijgen. Zoals getoond in figuur 4.8 erven deze klassen allemaal van de interface Windows zodat de windowprofiles er op een generische manier gebruik van kan maken (Mediator designpattern).

Figuur 4.8: Een klasse-diagram van de Windows.


77

Hardwaremanagers Harwaremanagers zijn hulpklassen voor het reserveren van de verschillende devices in de MHP-display-stack (Command design-pattern). Voor elke device bestaat er een manager: de BackgroundManager voor de background-device, de VideoManager voor de videodevice en tenslotte de GraphicManager voor de graphic-device. Figuur 4.9 geeft een klassediagram van deze klassen.

Figuur 4.9: Een klasse-diagram van de hardwaremanagers.

4.2.1 I b

De logica-laag

De logica-laag vormt een tussenlaag tussen de grafische laag en de library. Deze bijkomende laag zorgt ervoor dat de representatie gescheiden wordt van de functionaliteit en de data, zoals het geval is in het Model-View-Controller design-pattern. Dit heeft twee voordelen. Enerzijds is er geen redundantie in de verschillende representaties (windowprofiles) van de applicatie omdat alle gezamenlijke functionaliteiten in de logische laag vervat zijn. Anderzijds komt dit de aanpasbaarheid ten goede: de grafische laag is onafhankelijk van de library waardoor aanpassingen in de ene laag zich niet propageren in de andere. De logica-laag is opgebouwd uit verschillende controllers die samenhorende functionaliteiten bevatten. Zo bevat de ConnectionController bijvoorbeeld methodes voor het opzetten van een verbinding met een server en om in te loggen, de AccountController bevat dan weer functies om het account te beheren, enz.


4.2.1 I c

78

De interactie tussen de grafische en de logica-laag

De communicatie tussen de grafische laag en de logica-laag is bidirectioneel. Naast gewone functie-oproepen wordt er van twee andere mechanismen gebruik gemaakt voor ingewikkeldere interactiepatronen. Het eerste is het callback -mechanism dat gebruikt wordt in de volgende situatie. Een instantie van een window ontvangt gegevens van de gebruiker en roept een controller op om de gegevens te verwerken. Hierbij geeft de window-instantie zichzelf mee als parameter. Wanneer een fout optreedt bij de verwerking in de controller moet dit getoond worden in de window. Om dit te doen roept de controller de methode setFault(String) op op de meegekregen instantie van de window. Dit mechanisme wordt ook toegepast binnen de grafische laag om windows herbruikbaar te maken door verschillende oproepers, zoals bijvoorbeeld de SelectContactWindow. Het tweede is het Observer design-pattern. Het wordt door klassen van de grafische laag gebruikt om van wijzigingen van de buddy-list op de hoogte te blijven. Concreet implementeren deze klassen de Observer -interface en registreren ze zich bij een Observable-klasse, in dit geval de RosterController.

4.2.2

Verloop van de uitvoeringsdraden

Het verloop van de uitvoering van de applicatie is eenvoudig omdat er maar één uitvoeringsdraad gebruikt wordt. Er kunnen echter nieuwe uitvoeringsdraden aangemaakt worden door de library, bijvoorbeeld om een ontvangen pakket te verwerken. Door de interactie met de gebruiker resulteert dit in een combinatie van event-driven programming bij het wachten op invoer van de gebruiker en flow-driven programming voor de verwerking van de invoer. Een uitzondering hierop is de InvisibleWindowProfile waarbij alle ontvangen events in parallel verwerkt worden.


4.2.3

79

Input van de gebruiker

Er zijn in MHP vier verschillende manieren om de invoer van de gebruiker op te vangen, te onderscheiden volgens twee criteria: exclusiviteit van de ontvangen invoer en het gebruikte mechanisme. Er bestaan namelijk twee mechanismen om de invoer te ontvangen: AWT, waarbij de event wordt gestuurd naar de grafische component die de focus heeft, of repository, waarbij de event wordt doorgegeven aan een opgegeven opslagplaats. De vier verschillende manieren zijn dus: exclusieve AWT, niet-exclusieve AWT, exclusieve repository en niet-exclusieve repository. Omdat elke windowprofile een andere representatie geeft aan de applicatie betekent dit ook dat elke profile niet dezelfde invoer van de gebruiker verwacht of dezelfde methodes gebruikt om die invoer te ontvangen. De mechanismen gebruikt in de verschillende profiles worden nu kort besproken: • de startup-windowprofile heeft enkel nood aan de numerieke toetsen en de pijlentoetsen. Omdat het gedrag afhankelijk is van de grafische component die de focus heeft wordt het AWT-mechanisme gebruikt. In deze profile wordt gevoelige informatie ingevoerd, daarom moet er verhinderd worden dat andere applicaties deze informatie ook kunnen ontvangen. Om deze reden is de ontvangst van de invoer van numerieke toetsen exclusief. • Omdat de video nog zichtbaar is in de minimized-windowprofile, maakt deze gebruik van het klassieke AWT-mechanisme op een niet-exclusieve manier, zodat de gebruiker nog kan interageren met de tv (bv. van kanaal veranderen). Een uitzondering hierop zijn de kleurentoetsen, omdat deze een speciale rol spelen in deze profile. De reactie van de applicatie op de kleurentoetsen is namelijk onafhankelijk van de component die de focus heeft, zodat het repository-mechanisme beter geschikt is. Bovendien is de invoer van de kleurentoetsen exlusief zodat deze events niet interfereren met de werking van andere applicaties. • Omdat in de maximized-windowprofile enkel de applicatie zichtbaar is, wordt alle invoer voor dezelfde interferentieredenen exclusief ontvangen.


80

• De invisible-windowprofile moet alle events ontvangen om het herinneringsbericht te kunnen tonen, heeft geen focus en mag niet interfereren met andere applicaties, daarom wordt er gekozen voor een niet-exclusieve repository-methode.

4.2.4

Implementatie van tv-specifieke functionaliteiten

In de applicatie zijn twee tv-specifieke functionaliteiten ingebouwd die besproken zijn in 1.3, namelijk kunnen zien naar welk tv-programma contacten aan het kijken zijn en tv-programma’s aanbevelen. Bij de eerste functionaliteit wordt de naam van de zender en van het tv-programma toegevoegd aan de presence-status (zie 2.1.4 I b) van de gebruiker. Door het bestaande presence-mechanisme te gebruiken wordt de informatie automatisch verspreid en is het rechtstreeks zichtbaar voor de contacten. Een nadeel is dat deze methode onflexibel is. De applicatie van een contact kan namelijk niet het verschil maken tussen de tv-programmainformatie en de tekst opgegeven door de gebruiker. Daardoor kan deze informatie niet gebruikt of anders weergeven worden. Voor dezelfde functionaliteit maar dan voor muziek in de plaats van tv-programma’s is er reeds een extensie in ontwikkeling, namelijk JEP-0118 [97]. Een gelijkaardige extensie voor tv-programma’s zou een waardig en interoperabel alternatief bieden. Voor het versturen van aanbevelingen gebruikt IM4MHP klassieke berichten. Om het verschil te kunnen maken tussen een bericht en de aanbeveling, voegt IM4MHP ook een property (zie 4.1.3) toe. Dit verhindert interoperabiliteitsproblemen: andere XMPP-client ontvangt de aanbeveling als een gewoon bericht en negeert de property, terwijl IM4MHP de property detecteerd en de aanbeveling herkent.4

4.2.5

Externe code

Naast de library bevat IM4MHP een aantal klassen geschreven door derden. Enerzijds betreft dit de libraries voor het opvragen van: de lijst van zenders, informatie over de 4

Properties toevoegen om de aanwezigheid van specifieke inhoud te detecteren kan ook gebruikt worden voor het detecteren van tv-programma-informatie in presence-pakketten.


81

tv-programma’s en de zender die de gebruiker aan het bekijken is, zie [35]. Anderzijds bevat het een grafische component die toelaat om tekst te scrollen, zie [29].

4.2.6

Mogelijke uitbreidingen

In dit hoofdstuk worden enkele mogelijke uitbreidingen op IM4MHP voorgesteld. • De gebruikersgegevens kunnen opgeslagen worden in het persistente geheugen van de STB, zodat de gebruiker ze niet telkens hoeft in te voeren. • De basisversie van het chatroomprotocol waar IM4MHP gebruik van maakt, laat enkel toe om chatrooms met een standaardconfiguratie aan te maken. Met de extensie JEP-0045 [91] is het mogelijk om de configuratie van de room op te geven. Een paar voorbeelden hiervan zijn de toegang van een chatroom beveiligen met een paswoord, het verbieden van private berichten tussen de gebruikers van de chatroom, de chatroom persistent maken, etc. Deze extensie is geïmplementeerd in de SMACK-library en aangepast aan MHP. • Nieuwe windowprofiles kunnen toegevoegd worden aan IM4MHP, die een meer gebruiksvriendelijke en intuïtieve interactie met de applicatie toelaten. • XMPP-extensies die bijzonder interessant kunnen zijn voor social networking en dus iDTV in het algemeen, zijn diegenen die behoren tot de “Extended Presence Protocol Suite” gedefinieerd in JEP-0119 [98]. Deze extensies laten toe om de gewone presence-informatie uit te breiden met allerlei andere informatie over de gebruiker. De meest interessante voor iDTV zijn: de bezigheid (JEP-0108 [56]), stemming (JEP-0107 [103]) of avatar 5

5

(JEP-0084 [104]) van de gebruiker.

De avatar van een gebruiker is een kleine afbeelding die ermee geassocieerd is. Dit hoeft geen representatie van fysieke persoon te zijn maar kan evengoed een afbeelding zijn die zijn stemming uitdrukt.


4.3

82

De testopstelling

De gebruikte testopstelling is gerepresenteerd in figuur 4.10. Succesvolle testen op deze opstelling garanderen de compabiliteit met de XMPP-referentie-server (jabber.org) en interoperabiliteit met zowel andere XMPP-clients als andere toestellen. Bovendien is IM4MHP getest op zowel de IRT-emulator als de OSMOSYS-emulator zodat de applicatie compatibel is met beide implementaties wat, zoals besproken in 4.5, niet zo vanzelfsprekend is.

Figuur 4.10: Een voorstelling van de testopstelling.

4.4

Vervulling van de vereisten

IM4MHP biedt de volgende functionaliteiten aan: • een nieuw account aanmaken op een XMPP-server; • inloggen op een account;


83

• real-time berichten ontvangen en versturen; • chatsessies houden; • communiceren met verschillende personen in chatrooms en private berichten sturen en ontvangen in chatrooms; • aanbevelingen van tv-programma’s versturen en ontvangen; • basisbeheer van het account: het paswoord wijzigen en het account vernietigen; • de eigen presence-informatie wijzigen; • automatisch de naam van de bekeken zender toevoegen aan de presence-status; • de presence-informatie van contacten in de buddy-list opvragen; • de buddy-list aanpassen (contacten toevoegen, verwijderen, verplaatsen naar een andere groep, een nieuwe groep aanmaken); • aanvragen voor de registratie op de buddy-list ontvangen; • de namen van de andere resources en hun prioriteit opvragen, en de prioriteit van deze resource instellen; • wisselen tussen de verschillende representaties van de applicatie; Elke XMPP-client kan communiceren met IM4MHP, ongeacht het onderliggend toestel of platform. IM4MHP voldoet dus aan alle vereisten opgesteld in 1.5 buiten twee uitzonderingen. Ten eerste is het in IM4MHP niet mogelijk om te communiceren met andere IM-diensten omdat er geen ondersteuning is voor de communicatie met transporten (zie 2.2.1) in de SMACK-library (JEP-0100 [106]). De tweede uitzondering is dat IM4MHP geen gebruik maakt van encryptie. De oorzaak daarvan ligt bij MHP en wordt besproken in 4.5. Zoals eerder vermeld werd bij het ontwikkelen van IM4MHP niet de nadruk gelegd op gebruiksvriendelijkheid zodat aan dit kwaliteitsattribuut maar in zekere mate voldaan wordt.


4.5

84

Problemen bij het implementeren voor MHP

Er zijn twee problemen die optreden bij het ontwikkelen voor MHP. Een eerste probleem treedt op bij het gebruiken van de grafische HAVi-componenten. Zowel het gedrag als de representatie van deze componenten zijn onvoldoende precies gespecificeerd in de MHP-standaard [26]. Daardoor ziet dezelfde applicatie er niet alleen anders uit afhankelijk van de gebruikte implementatie van MHP, maar kan de compatibiliteit bovendien verschillen van implementatie tot implementatie. Een concreet voorbeeld hiervan is de methode getSelection() van de klasse HListGroup. Wanneer er geen selectie is geeft deze methode een lege lijst terug bij de IRT-implementatie en een null-pointer bij de OSMOSYS-implementatie. Om een applicatie te ontwikkelen die onafhankelijk is van de gebruikte MHP-implementatie, is het dus aan te raden om de HAVi-componenten te vermijden en in de plaats zelfgemaakte grafische componenten te gebruiken. Ten tweede zorgen de strenge veiligheidsmaatregelen van MHP voor complicaties. MHP ondersteunt namelijk TLS maar, zoals vermeld in hoofdstuk 12.10.3 van [26], laat het het gebruik ervan enkel toe als het certificaat van de server vertrouwd kan worden en dus lokaal aanwezig is. Dit betekent dat voor elke XMPP-server waarop de gebruiker mogelijk kan inloggen een vertrouwd certificaat aanwezig moet zijn. Bovendien is het niet altijd gemakkelijk om het certificaat van een server te achterhalen. Voor die redenen, en ook omdat IM4MHP eerder bedoeld is voor recreatieve doeleinden, werd er gekozen om encryptie achterwege te laten in afwachting van een oplossing.6

4.6

Verschil tussen IM4MHP en AmigoTV

Een andere IM-client voor iDTV is de door Alcatel ontwikkelde AmigoTV7 [16]. Ondanks dat IM4MHP en AmigoTV beide XMPP gebruiken als IM-protocol, kiezen ze beide toch voor een totaal verschillende aanpak, vooral wat betreft de interactie met de 6

Waarschijnlijk hebben praktisch alle XMPP-servers certificaten van CAcert of StartCom zodat de aanwezigheid van hun root-certificaten een oplossing kan bieden. Deze oplossing werd echter niet getest. 7 De IM-client is maar een onderdeel van AmigoTV. AmigoTV is een totaal-oplossing voor triple-play.


85

gebruiker. Terwijl bij IM4MHP de interactie met de gebuiker gebeurt aan de hand van statische vensters, een aanpak die sterk aanleunt bij de IM-applicaties voor computer, maakt AmigoTV veeleer gebruik van visuele informatie (avatars, emoticons, ...) om de mening en emoties van de gebruiker uit te drukken, en worden de berichten op een dynamische manier op het scherm getoond. Er liggen twee kwesties aan de basis van deze verschillen. Enerzijds is AmigoTV niet interoperabel met andere applicaties en laat het enkel communicatie toe tussen tv-gebruikers. Hierdoor kan de weergave geoptimaliseerd worden voor dit type communicatie (laag debiet en korte berichten) en kunnen de protocollen naar behoefte aangepast worden. IM4MHP laat daarentegen ook communicatie toe met andere types toestellen, waardoor er bij de weergave ook rekening moet worden gehouden met andere communicatieprofielen. Omdat de invoer van tekst op een computer veel gemakkelijker is, kan de grootte en het debiet van de berichten bijvoorbeeld veel hoger liggen. Anderzijds hebben AmigoTV en IM4MHP een andere achtergrond. In tegenstelling tot IM4MHP, is AmigoTV niet ontstaan uit een zuiver technisch standpunt, maar ook uit een business-perspectief. Het houdt daarom rekening met mogelijke inkomsten, zoals bijvoorbeeld het personaliseren van de toepassing door emoticons en avatars te verkopen. Door enkel communicatie toe te laten tussen tv-gebruikers en een dynamische GUI aan te bieden, is AmigoTV beter geschikt voor social networking. IM4MHP heeft echter onbetwistbare voordelen als bijvoorbeeld interoperabiliteit met andere toestellen. Bovendien is het, door de uitbreidbare architectuur van de GUI, mogelijk om nieuwe representaties toe te voegen aan de applicatie. Zo is het mogelijk om een representatie toe te voegen die een gelijkaardig weergavesysteem als AmigoTV aanbiedt. Het integreren van extensies die extended-presence mogelijk maken kan hierbij een belangrijk hulpmiddel zijn.

Hoofdstuk 5 Besluit en toekomstperspectieven Het aanbieden van een IM-systeem op iDTV is meer dan enkel de standaardfunctionaliteiten van een IM-systeem op een iDTV-platform implementeren. Door de specifieke eigenschappen van de tv worden namelijk nieuwe toepassingen mogelijk die IM een meerwaarde geven, zoals die besproken in 1.3. De ontwikkelde IM-client IM4MHP implementeert er twee: tv-programma’s aanbevelen en de contacten van een gebruiker laten weten naar welk tv-programma hij/zij aan het kijken is. Nieuwe mogelijkheden kunnen ook ontstaan door het integreren van de IM-applicatie met andere toepassingen voor iDTV. Zo kan een elektronische identiteitskaart een gebruiksvriendelijk alternatief bieden voor het paswoord bij het inloggen op een IM-account (zie ook [9]). De IM-client kan uitgebreid worden met VoIP, VOD (video-on-demand, zie ook [23]) en video-conferencing om tot een volledige triple-play oplossing te komen. Interactie met een EPG (Electronic program guide) kan dan weer interessant zijn voor het verwerken van ontvangen aanbevelingen. De EPG kan de gebruiker bijvoorbeeld de mogelijkheid aanbieden om het aanbevolen tv-programma aan zijn playlist toe te voegen. Tenslotte kan de IM-applicatie gebruikt worden bij t-learning [18] om de verschillende gebruikers met elkaar te laten communiceren. iDTV stelt reclamemakers en tv-zenders voor een nieuwe uitdaging omdat gebruikers de traditionele reclame kunnen doorspoelen.[48] Dit zorgt ervoor dat er nieuwe methodes moeten gevonden worden om inkomsten te halen uit iDTV. IM kan hierbij een belangrij-

86

Hoofdstuk 5. Besluit en toekomstperspectieven

87

ke rol spelen. IM kan als alleenstaande toepassing inkomsten genereren, door bijvoorbeeld het programma aan te bieden tegen betaling of voor het personaliseren ervan, zoals het geval is bij AmigoTV. De andere gebruiksmogelijkheden van het IM-protocol XMPP kunnen echter ook bijdragen tot het ontwikkelen van nieuwe methodes om inkomsten te genereren, in het bijzonder wanneer ze gekoppeld worden aan een t-commerce- of betalingssysteem (zie [21] voor een bespreking van t-commerce). Een voorbeeld hiervan zijn de impuls-aankopen besproken in 3.1.2 I e. IM biedt dus zowel op technologisch als op commercieel vlak heel veel mogelijkheden. Door de beperkingen blijft het echter moeilijk te voorspellen of IM de hoge verwachtingen zal inlossen en erin zal slagen om van de tv een hypersociaal medium te maken.

Appendix A: Inhoud van de CD-ROM De CD-ROM bevat de volgende zaken: • een pagina die al deze informatie herhaalt en verwijzingen bevat naar de inhoud van de CD-ROM onder de naam “Inhoud.htm” in de hoofdmap; • een elektronische versie van dit boek in pdf-formaat onder de naam “IM4MHP.pdf” in de hoofdmap; • de source code van IM4MHP in de map “IM4MHP\src”; • de gecompileerde code van IM4MHP in de map “IM4MHP\bin”; • de java documentatie (javadoc) van IM4MHP in de map “IM4MHP\javadoc”; • jars van zowel IM4MHP als de aangepaste SMACK-library in de map “IM4MHP\jars”; • het volledige Eclipse-project in de map “IM4MHP”, voor de werking ervan zijn de MHP stubs toegevoegd in de map “MHP\stubs”.

88

Bibliografie [1] J. Abreu, P. Almeida & V. Branco (2001). 2BeOn: Interactive television supporting interpersonal communication. In Proceedings of the sixth Eurographics workshop on Multimedia 2001, pp. 199–208. [2] D. Adams (2006). Jep-0009: Jabber-RPC. [3] A.L.I.C.E. AI Foundation, Inc. (2006). A.L.I.C.E. Artificial Intelligence Foundation. http://www.alicebot.org/, gelezen op 23/05/2006. [4] Asterisk IM (2006). Asterisk IM: Powerful Asterisk and XMPP integration. http: //www.jivesoftware.org/asterisk-im/, gelezen op 20/05/2006. [5] L. Bass, P. Clements & R. Kazman (2003). Software Architecture in Practice, Second Edition. Addison-Wesley Professional. [6] J. Beda, P. Saint-Andre, S. Ludwig & J. Hildebrand (2006). Jep-0176: Jingle RTPICE Transport. [7] J. Beda, P. Saint-Andre, S. Ludwig & J. Hildebrand (2006). Jep-0177: Jingle Raw UDP Transport. [8] T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler & F. Yergeau (2004). Extensible Markup Language (XML) 1.0 (Third Edition). [9] J. Cammaert (2006). Integratie van de Belgische elektronische identiteitskaart op het MHP platform.

89

Bibliografie

90

[10] B. Campbell, R. Mahy & C. Jennings (2006). The Message Session Relay Protocol. Internet draft (work in progress). http://www.ietf.org/internet-drafts/ draft-ietf-simple-message-sessions-14.txt, gelezen op 19/05/2006. [11] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema & D. Gurle (2002). Session initiation protocol (sip) extension for instant messaging, rfc 3428. [12] M. Campe (2003). Gedistribueerd brengen van nieuws. [13] F. Cano & P. Saint-Andre (2006). Jep-0179: Jingle IAX Transport Method. [14] M. Chuah (2002). Reality Instant Messenger: The promise of itv delivered today. In Proceedings of the AHA’2002 Workshop on Personalization in Future TV. [15] CollabNet, Inc. (2006). Jxta: Get connected. http://www.jxta.org/, gelezen op 22/05/2006. [16] T. Coppens, K. Handekyn & F. Vanparijs (2005). Amigotv: A Social TV Experience Through Triple-Play Convergence. Technical report, Alcatel. [17] M. Day, S. Aggarwal & J. Vincent (2000). Instant Messaging / Presence Protocol Requirements, RFC 2779. [18] T. De Pessemier (2006). Analyse en ontwerp van een framework voor educatieve televisie op het mhp-platform. [19] De Standaard (2005). Belgacom TV heeft ruim 20.000 klanten, 16/11/2005. [20] De Tijd, TNL & Het Nieuwsblad (2006). Belgacom TV haalt doelstellingen niet, 3/03/2006. [21] P. Deconinck (2006). Analyse en ontwerp van een t-commerce MHP applicatie voor interactieve digitale televisie. [22] H. Deitel, P. Deitel & S. Santry (2002). Advanced Java 2 Platform, chapter 28: Peer-to-Peer Applications and JXTA. Prentice Hall.

Bibliografie

91

[23] K. Demeyere (2006). Analyse en Ontwerp van een Applicatie voor Videoconferencing & Live Event Broadcasting. [24] T. Dierks, C. Allen, W. Treese, P. Karlton, A. Freier & P. Kocher (1999). The TLS Protocol Version 1.0, RFC 2246. [25] C. Dodson (2000). Jabber Technical White Paper. Technical report, Jabber.com, Inc. [26] European Telecommunications Standards Institute (ETSI) (2003). Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3. [27] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach & T. Berners-Lee (1999). Hypertext Transfer Protocol – HTTP/1.1, RFC 2616. [28] F. Forno & P. Saint-Andre (2005). Jep-0072: SOAP Over XMPP. [29] M. Frattallone (2006).

Mframework project home page. http://mframework.

sourceforge.net/, gelezen op 01/06/2006. [30] GAIM (2006). Gaim 1.5.0 A multi-protocol instant messaging (IM) client. http: //gaim.sourceforge.net/, gelezen op 20/05/2006. [31] M. Garcia-Martin, M. Isomaki, G. Camarillo & S. Loreto (2006).

A Me-

chanism to Enable File Transfer with the Session Initiation Protocol (SIP). Internet draft (work in progress). http://www.ietf.org/internet-drafts/ draft-garcia-sipping-file-transfer-mech-00.txt, gelezen op 19/05/2006. [32] Gizmo (2006). The Gizmo Project. http://www.gizmoproject.com/, gelezen op 20/05/2006. [33] Google Talk (2006). http://www.google.com/talk/, gelezen op 20/05/2006. [34] M. Gudgin, M. Hadley, N. Mendelsohn, J. Moreau & H. Nielsen (2004). SOAP Version 1.2 Part 1: Messaging Framework. [35] S. Hennebel (2006). Ontwerp van een intelligente epg voor het MHP-platform.

Bibliografie

92

[36] J. Hildebrand, P. Millard, R. Eatmon & P. Saint-Andre (2006). Jep-0030: Service Discovery. [37] J. Hildebrand & P. Saint-Andre (2004). Jep-0115: Entity Capabilities. [38] N. Iacobacci (2006). What makes a good interactive application really good. 21-22 Februari, IRT Munich. [39] IETF (2006). The Internet Engineering Task Force. http://www.ietf.org/, gelezen op 19/05/2006. [40] IETF (2006).

http://www.ietf.org/ids.by.wg/simple.html, gelezen op

22/05/2006. [41] B. Irving, D. Rosensweig & B. Garlinghouse (2005).

Microsoft and Ya-

hoo! Press Teleconference. http://www.microsoft.com/presspass/exec/irving/ 10-12Yahoo.mspx, gelezen op 22/05/2006. [42] Jabber, Inc. (2006). Jabber XCP: developer options. http://www.jabber.com/ index.cgi?CONTENT_ID=622, gelezen op 25/05/2006. [43] Jabber, Inc. (2006). Resources: case studies. http://www.jabber.com/index.cgi? CONTENT_ID=34, gelezen op 22/05/2006. R :: JSF http://www.jabber. [44] Jabber Software Foundation (JSF) (2005). Jabber

org/jsf/, gelezen op 20/05/2006. [45] Jabber Software Foundation (JSF) (2005). Jabber :: Software :: Libraries. http: //www.jabber.org/software/libraries.shtml, gelezen op 26/05/2006. [46] J. Karneges, I. Paterson, J. Perlow & P. Saint-Andre (2006). Jep-0136: Message Archiving. [47] O. Kharif (2005).

Google-aol: The First Step to VoIP Interoperabili-

ty? http://www.businessweek.com/the_thread/techbeat/archives/2005/12/ google-aol_the.html, gelezen op 22/05/2006.

Bibliografie

93

[48] D. Kiley & T. Lowry (2005). The end of TV (as you know it). BusinessWeek, November 21, 2005. [49] kum (belga) (2006). Telenet verkocht reeds 100.000 digiboxen, 26/01/2006. [50] L. Lear (2004). Architectural Considerations for Presence and Instant Messaging Infrastructure. Comparing XMPP and SIP/SIMPLE. Technical report, Jabber, Inc. [51] S. Leggio (2004). Sip for Instant Messaging and Presence Leveraging Extensions. [52] M. Lonnfors & K. Kiss (2006).

Session Initiation Protocol (SIP) User

Agent Capability Extension to Presence Information Data Format (PIDF). Internet draft (work in progress). http://www.ietf.org/internet-drafts/ draft-ietf-simple-prescaps-ext-06.txt, gelezen op 19/05/2006. [53] S. Ludwig, J. Beda, P. Saint-Andre & J. Hildebrand (2006). Jep-0166: Jingle. [54] S. Ludwig & P. Saint-Andre (2006). Jep-0167: Jingle Audio Media Description Format. [55] G. Macchia (2005). Sip, RTP, and XMPP in the emerging real-time internet. Technical report, Jabber, Inc. [56] R. Meijer & P. Saint-Andre (2004). Jep-0108: User Activity. [57] D.

Mierla

(work

(2004). in

progress).

Simple-xmpp

Interworking.

Internet

draft

http://bgp.potaroo.net/ietf/all-ids/

draft-mierla-simple-xmpp-interworking-01.txt, gelezen op 19/05/2006. [58] P. Millard, P. Saint-Andre & R. Meijer (2005). Jep-0060: Publish-Subscribe. [59] J. Miller, D. Adams & P. Saint-Andre (2004). Jep-0022: Message Events. [60] M. Miller & P. Saint-Andre (2005). Jep-0079: Advanced Message Processing. [61] M. Mintz (2003). Msn Messenger Protocol, Research - Research Practice. http:// www.hypothetic.org/docs/msn/research/research_practice.php, gelezen op 22/05/2006.

Bibliografie

94

[62] D. Moore & W. Wright (2003). Jabber Developer’s Handbook. Sams Publishing. [63] D. Moore & W. Wright (2003). Jabber Developer’s Handbook. Sams Publishing. [64] S. Morris & A. Smith-Chaigneau (2005). Interactive TV Standards: A Guide to MHP, OCAP, and JavaTV. Focal Press. [65] R. Movva & W. Lai (1999). Msn Messenger Service 1.0 Protocol. http://www. hypothetic.org/docs/msn/ietf_draft.php, gelezen op 22/05/2006. [66] T. Muldowney, M. Miller & R. Eatmon (2004). Jep-0096: File Transfer. [67] J. Myers (1997). Simple Authentication and Security Layer (SASL), RFC 2222. [68] J. Newell (2002). An introduction to MHP 1.0 and MHP 1.1. Technical report, BBC R&D White Paper - WHP 030. [69] H. Nielsen, E. Christensen, S. Lucco & D. Levin (2001). Web Services Referral Protocol (WS-Referral). [70] H. Nielsen & S. Thatte (2001). Web Services Routing Protocol (WS-Routing). [71] A. Niemi, M. Lonnfors & E. Leppanen (2006).

Publication of Par-

tial Presence Information. Internet draft (work in progress). http://www. ietf.org/internet-drafts/draft-ietf-simple-partial-publish-04.txt, gelezen op 19/05/2006. [72] C. Noss, P. Gersch, T. Hofmann, T. Koch, B. Stockleben, N. de Abreu & A. Chouikhi (2006). Mhp Usability and Style Guide. MHP Knowledge Database (MHP-KDB). [73] OpenWengo (2006).

Openwengo. http://www.openwengo.org/, gelezen op

20/05/2006. [74] J. Postel (1980). User Datagram Protocol, RFC 768. [75] J. Postel (1981). Transmission Control Protocol, RFC 793. [76] J. Postel (1982). Simple Mail Transfer Protocol, RFC 821.

Bibliografie

95

[77] Psi (2006). Psi Jabber Client. http://psi-im.org/, gelezen op 20/05/2006. [78] C. Quico (2003). 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?, pp. 99–107. [79] B. Ron, J. Clark, A. Slominski & J. Strachan (2006). Jsr 173: Streaming API for XML. http://www.jcp.org/en/jsr/detail?id=173, gelezen op 01/06/2006. [80] J. Rosenberg (2004). A Presence Event Package for the Session Initiation Protocol (SIP), RFC 3856. [81] J. Rosenberg (2005).

Extensible Markup Language (XML) Formats for Re-

presenting Resource Lists. Internet draft (work in progress). http://www.ietf. org/internet-drafts/draft-ietf-simple-xcap-list-usage-05.txt, gelezen op 19/05/2006. [82] J. Rosenberg (2006). Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. Internet draft (work in progress). http://www.ietf.org/internet-drafts/ draft-ietf-mmusic-ice-08.txt, gelezen op 20/05/2006. [83] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley & E. Schooler (2002). Sip: Session Initiation Protocol, RFC 3261. [84] J. Rosenberg, H. Schulzrinne & P. Kyzivat (2004). Indicating User Agent Capabilities in the Session Initiation Protocol (SIP), RFC 3840. [85] J. Rosenberg, J. Weinberger, C. Huitama & R. Mahy (2003). STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), RFC 3856. [86] P. Saint-Andre (2004). End-to-end Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP), RFC 3923.

Bibliografie

96

[87] P. Saint-Andre (2004). Extensible Messaging and Presence Protocol (XMPP): Core, RFC 3920. [88] P. Saint-Andre (2004). Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, RFC 3921. [89] P. Saint-Andre (2004). Jep-0128: Service Discovery Extensions. [90] P. Saint-Andre (2004). Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM), RFC 3922. [91] P. Saint-Andre (2005). Jep-0045: Multi-User Chat. [92] P. Saint-Andre (2005). Streaming XML with Jabber/XMPP. IEEE Internet Computing. [93] P. Saint-Andre (2005). Xmpp-simple Feature Comparison. http://www.jabber. org/protocol/xmpp-simple.shtml, gelezen op 20/05/2006. [94] P. Saint-Andre (2006). Jep-0066: Out of Band Data. [95] P. Saint-Andre (2006). Jep-0071: XHTML-IM. [96] P. Saint-Andre (2006). Jep-0077: In-Band Registration. [97] P. Saint-Andre (2006). Jep-0118: User Tune. [98] P. Saint-Andre (2006). Jep-0119: Extended Presence Protocol Suite. [99] P. Saint-Andre (2006). Jep-0160: Best Practices for Handling Offline Messages. [100] P. Saint-Andre (2006). Jep-0181: Jingle DTMF. [101] P. Saint-Andre & M. Chen (2006). Jep-0180: Jingle Video Media Description Format. [102] P. Saint-Andre & J. Hildebrand (2006). Jep-0184: Message Receipts. [103] P. Saint-Andre & R. Meijer (2004). Jep-0107: User Mood.

Bibliografie

97

[104] P. Saint-Andre, P. Millard, T. Muldowney & J. Missig (2006). Jep-0084: User Avatar. [105] P. Saint-Andre & D. Smith (2005). Jep-0085: Chat State Notifications. [106] P. Saint-Andre & D. Smith (2005). Jep-0100: Gateway Interaction. [107] H. Schulzrinne (2005). Indication of Message Composition for Instant Messaging, RFC 3994. [108] H. Schulzrinne, S. Casner, R. Frederick & V. Jacobson (2003). Rtp: A Transport Protocol for Real-Time Applications, RFC 3550. [109] I. Shigeoka (2002). Instant Messaging in Java: The Jabber Protocols. Manning Publications. [110] A. Slominski (2006). Xml Pull Parsing. http://www.xmlpull.org/index.shtml, gelezen op 01/06/2006. [111] SMACK API (2006). Smack API: Simple and Powerful Java client API for XMPP. http://www.jivesoftware.org/smack/, gelezen op 20/05/2006. [112] D. Sosnoski (2006).

Xml documents on the run, Part 3. How do SAX2 par-

sers perform compared to new XMLPull parsers? http://www.javaworld.com/ javaworld/jw-04-2002/jw-0426-xmljava3-p2.html, gelezen op 01/06/2006. [113] M. Spencer, B. Capouch, E. Guy, F. Miller & K. Shumard (2006). Iax: InterAsterisk eXchange Version 2. Internet draft (work in progress). http://www.ietf. org/internet-drafts/draft-guy-iax-01.txt, gelezen op 21/05/2006. [114] Sun Microsystems, Inc. (2006). http://www.sun.com/, gelezen op 22/05/2006. [115] The Jabber Software Foundation (JSF) (2005). Jabber :: Software :: Clients. http: //www.jabber.org/software/clients.shtml, gelezen op 20/05/2006. [116] The Jabber Software Foundation (JSF) (2005). Jabber :: Software :: Components. http://www.jabber.org/software/components.shtml, gelezen op 20/05/2006.

Bibliografie

98

[117] The Jabber Software Foundation (JSF) (2005). Jabber :: Software :: Libraries. http://www.jabber.org/software/libraries.shtml, gelezen op 20/05/2006. [118] The Jabber Software Foundation (JSF) (2006).

Jabber :: JEPs. http://www.

jabber.org/jeps/, gelezen op 20/05/2006. [119] The Jabber Software Foundation (JSF) (2006). Jabber :: Software :: Servers. http: //www.jabber.org/software/servers.shtml, gelezen op 20/05/2006. [120] The University of Washington (2006).

Pine Information Center. http://www.

washington.edu/pine/, gelezen op 20/05/2006. [121] K. Verschaeve, T. Pijpops & F. Westerhuis (2002). Synergy Between Jabber Instant Messaging and Web Services. In International Conference on Internet Computing, pp. 797–803. [122] Wikipedia (2006).

Artificial Linguistic Internet Computer Entity From

Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Artificial_ Linguistic_Internet_Computer_Entity, gelezen op 22/05/2006. [123] Wikipedia (2006). Chatterbot From Wikipedia, the free encyclopedia. http://en. wikipedia.org/wiki/Chatterbot, gelezen op 22/05/2006. [124] Wikipedia (2006). Instant messaging From Wikipedia, the free encyclopedia. http: //en.wikipedia.org/wiki/Instant_messaging, gelezen op 22/05/2006. [125] Wikipedia (2006). Multimedia Home Platform From Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Multimedia_Home_Platform, gelezen op 22/05/2006. [126] Wikipedia (2006). Peer-to-peer From Wikipedia, the free encyclopedia. http://en. wikipedia.org/wiki/Peer-to-peer#Attacks_on_peer-to-peer_networks, gelezen op 22/05/2006. [127] D. Winer (1999). XML-RPC Specification. http: // www. xmlrpc. com/ spec , gelezen op 25/05/2006.

Bibliografie

99

[128] xmpp.org (2005). History of XMPP http://www.xmpp.org/history.html, gelezen op 20/05/2006.

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

Recommend Documents