XML-RPC över Jabber. ACM Classification. ACM Special interest groups. Abstrakt. 1. Inledning

Transkript

1 XML-RPC över Jabber Ronnie Snellman Department of Computer Science Åbo Akademi University, FIN Åbo, Finland URL: Oktober 2004 ACM Classification C.2.4 Distibuted systems C.2.6 Internetworking D.2.11 Software architectures ACM Special interest groups ACM SIGCOMM Abstrakt Jabber är ett XML-baserat protokoll som används för kommunikation över Internet, bl.a. vid Instant Messaging (liksom MSN, ICQ och Yahoo). Kommunikationen sker med hjälp av meddelanden, som skickas via XML-strömmar över HTTP. I denna artikel undersöks Remote Procedure Call (RPC) inpackade in Jabber-meddelanden. XML-RPC är en teknologi som implementerar RPC och som underlättar integrerandet av RPC och Jabber. 1. Inledning Användningen av Internet har tilltagit kraftigt under det senaste dicenniet. Därtill har intresset för distribution av tyngre datorberäkningar inom nätverk blivit allt vanligare. Genom att kombinera olika teknologier för utveckling av distribuerade system med kommunikation över Internet kan man bygga ett lättförståeligt och utbyggbart, distribuerat system. I denna artikel gås igenom en stegvis uppbyggnad av ett sådant system.

2 2. XML och RPC 2.1 XML XML står för Extensible Markup Language, vilket betyder utbyggbart märkningsspråk. Språket har tilltagit i popularitet under de senaste åren, för att strukturera både lagrad data och dataströmmar. Informationen struktureras genom att man märker olika delar med etiketter (en. Tags). Nedan visas ett exempel hur man kan använda sig av XML för att märka en enkel svensk fras gramatikaliskt. Texten innan märkning: Pelle sparkar boll. Den märkta texten: <sats> <subjekt>pelle</subjekt> <predikat>sparkar</predikat> <objekt>boll</objekt> </sats> För att peka ut de enskilda satsdelarna har man märkt dem med etiketter som berättar vilket element respektive ord utgör i satsen. En XML-ström är i korthet utbyte av data genom strömning av XML-fragment över en nätverksuppkoppling. Under en uppkopplingssessions livstid, mellan två enheter, utbyts två fullständiga XML-dokument - ett i varje riktning. Det första som skickas är dokumentbeskrivningen (en. Header) och den yttersta etiketten i varje dokument är <stream/>. [Ada02][Suo04] 2.2 Remote Procedure Call (RPC) RPC teknologin är mycket äldre än Internet, då det presenterades första gången redan 1984 av A.Birell och B.J.Nelson. RPC påminner om lokala metodanrop men kan utföras på en annan dator som finns i samma nätverk. Idén med RPC är att det skall finnas ett gränssnitt för fjärrmetodanrop, som påminner så mycket som möjligt om ett lokalt metodanrop. På så sätt behöver programutvecklaren inte skriva någon nätverkskod, utan kan koncentrera sig på själva funktionaliteten av det system han utvecklar. För att parterna i ett RPC-system skall förstå varandra, omskrivs metodanropen, parametrarna och metodsvaren till ett gemensamt format. Denna omskrivning kallas att ordna (en. Marshalling) parametrarna. [All03][R1] 2

3 2.3 Olika implementationer av RPC Det finns många olika implementationer av RPC, varav Sun RPC var en av de första. Senare kom CORBA, DCOM, JavaRMI, XML-RPC och SOAP. De två sistnämnda skiljer sig i det avseendet att kommunikationen sker ovanpå ett annat protokoll, närmare bestämt Hypertext Transfer Protocol(HTTP), medan de tidigare kommunicerar direkt över socketar. CORBA är en objektorienterad version av RPC, men den är relativt complex då den verkliga överföringen av data sker via binära eller ASCII strömmar, vilka inte är lika lättlästa som XML strömmar. Därför lämpar sig XML-RPC bättre för distribuerade webapplikationer. DCOM är Microsofts motsvarighet till CORBA och är mest användbar om också resten av systemet består av COM-komponenter (d.v.s. komponenter tillverkade av Microsoft). SOAP (Simple Object Access Protocol) är i princip en fortsättning på XML-RPC, med en hel del funktioner tillsatta. Detta har gjort SOAP mera invecklat, men det är fortfarande användbart.[ada02][stl01][all03][r2] 2.4 XML-RPC XML-RPC är en implementation av RPC där XML används för att ordna parametrarna i anropen och svaren och kommunikationen sker över HTTP. Senare i detta kapitel följer exempel på metodanrop och svar. Eftersom XML är en fristående standard, d.v.s inte beroende av något programmeringsspråk, är det mycket praktiskt att använda XML för att kommunicera inom system med komponenter skrivna i olika programmeringsspråk XML-RPC protokollet RPC-servern finns tillgänglig på en given URL (= Internetadress). Ett XML-RPC anrop sker i följande steg: 1. RPC-klienten (den anropande processen) gör ett metodanrop på vanligt vis, genom att ange metodnamn, parametrar och serveradress. 2. En XML-RPC klient packar in metodnamnet och parametrarna i XML och skickar ett HTTP POST-anrop till den angivna HTTP-servern. 3

4 3. Den anropade HTTP-servern tar emot ett POST-anrop och skickar vidare XML innehållet till en XML-RPC server. 4. XML-RPC servern parsar ut metodnamnet och parametrarna ur XML koden och anropar den önskade lokala metoden med de angivna parametrarna. 5. Metoden returnerar svaret till XML-RPC servern, som packar in svaret i XML. 6. HTTP-servern returnerar XML-paketet, som svar på HTTP POST-anropet. 7. XML-RPC klienten parsar ut svaret ur XML-paketet och returnerar det till RPCklientprogrammet. 8. RPC-klientprogrammet fortsätter exekveringen med det mottagna svaret. Det finns inget som hindrar en process från att vara både klient och server i ett XML- RPC-system, men för varje enskilt anrop har varje process antingen rollen som klient eller server. HTTP-protokollet är tillståndslöst, vilket betyder att två på varandra följande anrop inte på något sätt kan bindas till varandra. XML-RPC ärver denna egenskap och har alltså inte heller något tillstånd. Ifall tillstånd måste finnas i systemet, kan man implementera dessa i ett ovanpå liggande lager. [StL01][R4] XML-RPC meddelanden Ett XML-RPC-anrop börjar med etiketten <methodcall/> och svaret börjar med <methodresponse/>. I anropet kommer metodnamnet som följande i etiketthierarkin och det märks upp med etiketten <methodname/>. För att bifoga parametrar till ett metodanrop (eller svar) märker man dem med etiketten <params/>. Även om inga parametrar bifogas i anropet måste denna etikett finnas med. Inuti params-fragmentet listas sedan parametrarna med hjälp av etiketten <param/>, samt innanför den ifrågavarande datatyp, t.ex. <int/> eller <string/>. XML-RPC understöder bara ett begränsat antal datatyper, vilket leder till att man ibland måste översätta det använda programmeringsspråkets datatyp till motsvarande i XML-RPC. Vilka datatyper som XML-RPC understöder finns listade i appendix A. Alternativt till parametrarna i svarsmeddelandet kan man ange ett felmeddelande, med hjälp av etiketten <fault/>. Felmeddelandet innehåller endast ett element, vilket är av typen struktur, och använder etiketten <struct/>. Strukturen består i sin tur av två delar, faultcode och faultstring. Den 4

5 första delen är avsedd för programmet och den senare är läsbar också för användaren. Nedan följer exempelfragment på anrop-, svar- samt felmeddelande. [StL01] Metodanrop: <?xml version="1.0"?> <methodcall> <methodname> examples.squareroot </methodname> <params> <param> <value><int> 9 </int></value> </param> </params> </methodcall> Metodsvar: <?xml version="1.0"?> <methodresponse> <params> <param> <value><int> 3 </int></value> </param> </params> </methodresponse> Felmeddelande: <?xml version="1.0"?> <methodresponse> <fault> <value> <struct> <member> <name> faultcode </name> <value><int> 4 </int></value> </member> <member> <name> faultstring </name> <value><string> Too many parameters. </string></value> </member> </struct> </value> </fault> </methodresponse> På grund av att XML-RPC sker över HTTP krävs en beskrivning (en. Header) på varje skickat anrop. Detta för att web-servern skall veta vart anropet skall vidarebefordras. En beskrivning kan se ut som följande: 5

6 POST /target.php HTTP/1.0 User-Agent: PHP XMLRPC 1.0 Host: xmlrpc.usefulinc.com Content-Type: text/xml Content-Length: 216 URLen efter POST anger vart anropet skall dirigeras. Host anger vilken server som skall ta emot anropet. Content-Length anger hur många 8-bits tecken meddelandet innehåller (börjande efter beskrivningen) Säkerhetsaspekter vid XML-RPC HTTP påstås av kritiker inte vara designad för XML-RPC eftersom datatrafiken kan röra sig alltför fritt mellan olika datorer. En XML-RPC server blir vanligtvis refererad via en URL, som i princip även kunde peka på en vanlig HTML-sida. Det finns inget sätt att veta om en URL pekar på någon speciell typ av sida. XML-RPC gör det möjligt att komma åt flera olika metoder via ett POST-anrop till en och samma URL (man måste bara ange metodnamnet). Problemet är vad man skall låta XML-RPC servern göra ifall den blir kallad av en användare som förväntar sig en vanlig HTML-sida. En möjlighet vore att svara med ett prydligt meddelande i HTML, som berättar att ingen sida finns tillgänglig. Alternativt kunde man helt enkelt stänga av uppkopplingen. En del programutvecklare ser XML-RPC och andra protokoll som använder sig av HTTP som ett hot mot datorsäkerheten. Detta p.g.a. att HTTP och port 80 getts alla rättigheter att komma in i en dator för att t.ex. leverera internetsidor. På samma sätt kan XML-RPCanrop ta sig igenom diverse skyddssystem såsom brandmurar, proxyn och olika typer av filter. [StL01] 3. Jabber RPC 3.1 Jabber som kommunikationsmedium Jabber är en kommunikationsteknologi baserad på XML-strömmar för kommunikation över HTTP, mellan två eller flera datorer. Detta vanligaste användningområdet av Jabber är Instant Messaging (IM). Trots att anrop över HTTP är synkrona, kan Jabberkommunikationen ses som asynkron. Detta p.g.a att mellan anropet och svaret, som sker i varsin XML-ström (en klient->server och en server->klient), kan förekomma XMLfragment som inte har med anropet att göra. För att para ihop ett metodanrop med dess 6

7 svar används ett unikt identifikationsattribut i meddelandena. En Jabber-server har en komponent kallad Jabber Session Manager (JSM), som koordinerar en session mellan två eller flera klienter. Ifall inte mottagaren av ett meddelande är inloggad sparar JSM meddelandet i en kö tills denne loggar in, varpå meddelandet levereras. När en klient loggar in till en Jabber-server underrättar JSM alla klientens kollegor att denne loggat in. På motsvarande sätt meddelas samtliga förändringar i en klients status åt dennes kollegor. Protokollet som JSM implementerar kallas Extensible Messaging and Presence Protocol (XMPP). Mellan entiteterna i Jabber skickas element av tre olika typer: Message, Info/Query (IQ) och Presence (sv. Meddelande, Info/Förfrågan och Närvaro). Varje elementtyp har en viss funktion i systemet. Se tabellen i appendix B för de olika elementens egenskaper. [R5][R6] I och med att Jabber är baserat på XML, och således utbyggbart, kan man använda protokollet för mycket annat än bara IM. I Jabber används flitigt en av XML-standardens viktiga funktioner, s.k. namnrymder (en. Namespace). Namnrymder används för att markera vart ett XML-fragment tillhör, vilket är viktigt vid utbyggande av protokollet. För Jabber-elementen message och presence används etiketten <x/>, för att ange en extension av elementet. På motsvarande sätt används etiketten <query/> för IQ-element. För att ge en referens åt ett fragment används argumentet xmlns (förkortning av XML namespace). Se XML-fragmentet nedan för exempel. [Ada02][Suo04] <message type= chat from= sender@work to= reciever@home > <subject> Hejsan! </subject> <body> Hej hur mår du? Här får du en intressant länk: </body> <x xmlns= jabber:x:oob > <url> </url> <desc> The official Jabber site. </desc> </x> </message> Ett typiskt Jabber-meddelande. <subject/> och <body/> etiketterna är triviala, medans <x/> etiketten är en extension av message-elementet. 3.2 XML-RPC via Jabber Hittills har behandlats två skilda teknologier som använder sig av XML: XML-RPC för representation av RPC anrop och Jabber för överföring av strukturerad data mellan entiteter i ett distribuerat nätverk. Nästa steg är att slå ihop dessa, d.v.s. göra metodanrop 7

8 via Jabber. Detta är enkelt p.g.a. att både Jabber-meddelanden och XML-RPC är representerade i XML. 3.3 Förberedelser För att kunna sätta igång ett Jabber XML-RPC system krävs en del förberedelser innan klienterna kan kommunicera med varandra. Systemet kommer att utnyttja IM konceptet som i Jabber är implementerat med XMPP. Såväl metodanroparen som svararen måste vara registrerade Jabber-användare, d.v.s. ha ett unikt Jabber-id (JID) samt ett lösenord. Registreringen sker enklast med hjälp av någon grafisk Jabber klient, t.ex. Exodus. Därefter måste vardera klient gokänna sin kollega genom en s.k. anhållan (en. Subscription), vilket innebär att en klient A önskar sätta till en ny kontakt, klient B, till sin kontaktlista och skickar en förfrågan på detta till en Jabberserver. Servern frågar i sin tur lov av klient B om huruvida A får lägga till denne i sin kontaktlista. Ifall B gokänner det, skickas en verifikation via servern till klient A och denne får automatiskt en förfrågan om huruvida B får lägga till A. Detta blir det naturliga scenariot i detta fall, trots att man vanligtvis inte gokänner kontakter, som man inte känner från verkliga livet, allt för att förhindra eventuella trakasserier. Ifall en anhållan inte gokänns av motparten sker heller inte tillägget i kontaktlistan. När väl två klienter har varandra i sina kontaktlistor kan de börja kommunicera. Enligt XMPP finns ett antal tillstånd (en. Status) en klient kan befinna sig i, såsom available, offline, away och do-not-disturb. Dessa tas vanligtvis i beaktande innan meddelanden skickas. Om en klient befinner sig i sitt tillstånd do-not-disturb, betyder det troligtvis att denne inte vill ha några meddelanden och skall då inte heller utsättas för sådana. Detta tillstånd kunde, i ett RPC-system, intas under själva beräkningen av en uppgift, som klienten fått. Självklart kan en klient inte ta emot något anrop då denne är inte är inloggad, men ifall ett anrop mot förmodan skickas sker ingen större skada än att anroparen får vänta på svaret tills mottagaren loggat in och är beredd att ta emot ett anrop. [Ada02] 8

9 4. Implementation 4.1 Beskrivning av systemet Som ett enkelt test av Jabber XML-RPC implementeras här ett litet system med två Jabber klienter, A och B, som loggar in till en lokal Jabber-server (körs på samma fysiska maskin). Klient A agerar XML-RPC klient och B XML-RPC server. A anropar B med ett XML-RPC anrop inbakat i ett meddelande (av typ message), där subject får vara XML- RPC och body innehåller XML-RPC delen. Efter att A skickat meddelandet blir den att vänta på svaret från B. När svaret anländer parsas svaret ut och skrivs ut på skärmen. Klient B börjar lyssna efter anrop direkt efter inloggningen. Då ett anrop anländer skickas XML-fragmentet i body-delen vidare till ett objekt av klassen XmlRpcServer, som i sin tur anropar den efterfrågade metoden. XmlRpcServern returnerar svaret och B skapar ett nytt meddelande, där subject sätts till XML-RPC response och body till svaret. Mottagaren av det nya meddelandet sätts till klient As id. 4.2 Jabber RPC servern Till servern behövs två klasser: huvudklassen som benämns JabberRPCServer samt en arbetarklass, AreaHandler, som tillhandahar den önskade metoden. I detta exempel skall arean av en cirkel beräknas och således tas ett värde på radien in och arean returneras. Både radien och arean är av datatypen double. Metoden som returnerar arean får heta circlearea: public class AreaHandler{ public AreaHandler(){ public static Double circlearea(double radius){ double value=(radius*radius*math.pi); return new Double(value); //returnerar ett objekt, d.v.s en Double. Själva serverklassen implementerar gränssnittet PacketListener och innehåller därmed metoderna start, receivepacket, sentpacket och sendfailed. De två sistnämnda är ointressanta i detta exempel och behandlas inte här. Däremot presenteras de första två längre fram i texten. Först kommer en lista över nödvändiga parametrar samt konstruktorn och main-metoden. 9

10 public class JabberRPCResponder implements PacketListener{ private String server = "localhost"; private String user = jrpcserver"; private String passwd = "jrpc"; private String resource = "rpc"; private XmlRpcServer responder; private ConnectionBean cbean; //testet körs på localhost //XmlRpcServer tar hand om det anlända anropet //ConnectionBean sköter uppkopplingen till Jabber-servern public JabberRPCResponder(){ responder = new XmlRpcServer(); responder.addhandler("area", new AreaHandler()); //en AreaHandler binds till strängen area public static void main(string[] args){ JabberRPCResponder server = new JabberRPCResponder(); try{ server.start(); catch(exception e){ System.out.println("Cannot start server: "+e.tostring()); Inloggningen till Jabber-servern sker i start-metoden public void start() throws Exception{ cbean = new ConnectionBean(); InetAddress addr; cbean.addpacketlistener(this); cbean.connect(addr=inetaddress.getbyname(server)); // InfoQueryBuilder används för att bygga ett IQ-element. InfoQueryBuilder iqb = new InfoQueryBuilder(); // IQAuthBuilder bygger ett IQ-element av typen authorization // vilket används för att logga in till Jabber-servern. IQAuthBuilder iqauthb = new IQAuthBuilder(); iqb.settype("set"); // inloggningsparametrarna sätts. iqauthb.setusername(user); iqauthb.setpassword(passwd); iqauthb.setresource(resource); // IQ-elementet får en extension. iqb.addextension(iqauthb.build()); // Ett IQ-meddelande skapas och sänds. InfoQuery iq = (InfoQuery)iqb.build(); cbean.send(iq); // Ett Presence-meddelande skapas och sänds. PresenceBuilder pb = new PresenceBuilder(); cbean.send(pb.build()); Metoden receivepacket följer näst: 10

11 public void receivedpacket(packetevent pe){ Packet pack = pe.getpacket(); System.out.println("RECV: " +pack.tostring()); // Behandlar bara paket av typen Message if(pack instanceof Message){ // Endast ifall subject stämmer processeras meddelandet if(((message)pack).getsubject().equals("xml-rpc")) { // Diverse information plockas ur meddelandet String request = ((Message)pack).getBody(); String id = ((Message)pack).getIdentifier(); JID from = ((Message)pack).getFromAddress(); // XML-RPC anropet transformeras till en BytArrayInputStream // pga a XmlRpcServern tar en sån som inputparameter. ByteArrayInputStream bis = new ByteArrayInputStream(request.getBytes()); // Anropet exekveras och resultatet lagras i en sträng. String result = new String(responder.execute(bis)); String response = result; // Innehålls definitionen tas bort så en sådan ju // redan finns för kommunikationsströmmen. int pos = result.lastindexof("?>"); if(pos>=0) response = result.substring(pos+2); else // Ett meddelande byggs MessageBuilder msgb = new MessageBuilder(); msgb.setsubject("xml-rpc response"); msgb.setbody(response); msgb.settoaddress(from); msgb.setidentifier(id); Message msg; try{ msg = (Message)msgb.build(); catch(instantiationexception ie){ System.out.println("Build failed: " +ie.tostring()); return; // Meddelandet sänds cbean.send(msg); //Should return a error message System.out.println("wrong type of message received!!!"); 4.3 Jabber RPC Klienten Jabber RPC klienten utgörs liksom servern av en Jabberklient och har därför till stor del liknande kodfragment. Vid inloggningen använder sig klienten av sina egna användarparametrar: private String server = "localhost"; private String user = jrpcklient"; private String passwd = "jrpc"; private String resource = "rpc"; 11

12 Början av start metoden ser också likadan ut, medan man i slutet skapar ett meddelande innehållande själva XML-RPC-anropet. För att underlätta konstruerandet av meddelandet används en hjälpklass vid namn PayloadBuilder (se författarens hemsida: rosnellm/jabberrpc). // Ett meddelande, innehållande metodanropet byggs MessageBuilder msgb = new MessageBuilder(); msgb.setsubject("xml-rpc"); // PayloadBuilder används för att bygga själva XML-RPC anropet PayloadBuilder plb = new PayloadBuilder(); plb.sethandler("area"); plb.setmethod("circlearea"); // Vi testar med radien = 10. plb.addparameter("double","10"); msgb.setbody(plb.build()); msgb.settoaddress(jid.fromstring(xmlrpcserver+"@"+server)); Message msg; try{ msg = (Message)msgb.build(); catch(instantiationexception ie){ System.out.println("Build failed: " +ie.tostring()); return; cbean.send(msg); Metoden receivepacket i klienten är likaså mycket lik den i servern, med den skillnaden att det mottagna meddelandet här parsas för att få ut svaret på metodanropet. Parsandet sker med hjälp av klassen PayloadExtractor. Metoden receivepacket ser ut på följande sätt: public void receivedpacket(packetevent pe){ Packet pack = pe.getpacket(); // Behandlar bara paket av typen Message if(pack instanceof Message){ // Kollar så att subject stämmer if(((message)pack).getsubject().equals("xml-rpc response")) { // XML-RPC svaret plockas ur body och parsas av PayloadExtractor String response = ((Message)pack).getBody(); PayloadExtractor ple = new PayloadExtractor(); ple.parse(response); System.out.println("RESPONSE: "+ple.getresponse()); Vid körningen av systemet skall först och främst Jabber-servern vara igång. Sen startas JabberRPCResponder (RPC servern) och till sist JabberRPCRequester (RPC klienten). I detta fall kommer följande att skrivas ut på skärmen: RESPONSE: , då det är 12

13 arean av en cirkel med radien 10. Koden för hjälpklasserna samt de presenterade klasserna i sin helhet finns på författarens hemsida. 5. Sammanfattning I denna uppsats har gåtts igenom de steg som krävs för att bygga ett RPC systen över Jabber. De teknologier som använts har alla varit välkända och bra dokumenterade, så utmaningen låg i att kombinera byggstenarna på ett fiffigt sätt. Resultatet blev en lättförståelig distribuerad applikation, där styrkan ligger i det enkla sättet att kommunicera, d.v.s. genom meddelanden. Dessutom finns öppna Jabber-servrar på många ställen i världen vilket gör globala distribuerade system enkla att implementera. En av nackdelarna, jämfört med ett system implementerat direkt över socketar, är att kommunikationen blir mycket långsammare. Detta har dock inte så stor betydelse om applikationen är mera beräknings- än kommunikationsintensiv. Dessutom har Jabber meddelanden lätt att ta sig fram genom t.ex. brandmurar och därför kräver ett system som kommunicerar via Jabber knappt någon konfiguration av andra program. Slutsatsen är att man gått och väl kan använda sig av XML-RPC över Jabber ifall applikationen som man skall göra inte förutsätter snabb kommunikation eller understöd av datatyper som XML- RPC inte understöder. Referenser Böcker: [Ada02] Adams, DJ (2002) Programming Jabber, Extending XML Messaging. USA: O Reilly. [StL01] St.Laurent, Simon, Joe Johnston, Edd Dumbill (2001) Programming Web Services with XML-RPC. USA: O Reilly. Artiklar: [All03] Allman, Mark (2003) An Evaluation of XML-RPC ACM SIGMETRICS Performance Evaluation Review 30 (4), s

14 [Suo04] Suonveri, Mika (2004) Metaspråket XML. Department of Computer Science Åbo Akademi University. ( Webmaterial: [R1] XML-RPC for Newbies: [R2] HTTP Hypertext Transfer Protocol Overview: [R3] DCOM, CORBA, Java-RMI A step by step comparison by Gopalan Suresh Raj: [R4] Web Naming and Addressing Overview(URIs, URLs ): [R5] Jabber Software Foundation: [R6] Extensible Messaging and Presence Protocol (XMPP): [R7] Developer s introduction to JAX-RPC, Part 1: Learn the ins and outs of the JAX- RPC typemapping system: Appendix A: XML-RPC understöder följande datatyper: Type Int String Boolean Double DateTime.iso8601 base64 Array A signed, 32-bit integer. Properties An ASCII string, which may contain NULL bytes. (Actually, several XML- RPC implementations support Unicode, thanks to the underlying features of XML.) Either true or false. A double-precision floating point number. (Accuracy may be limited in some implementations.) A date and time. Unfortunately, since XML-RPC forbids the use of timezones, this is very nearly useless. Raw binary data of any length; encoded using Base64 on the wire. Very useful. (Some implementations don't like to receive zero bytes of data, though.) An one-dimensional array of values. Individual values may be of any type. 14

15 Struct A collection of key-value pairs. The keys are strings; the values may be of any type. Appendix B: Följande tre element utgör de meddelanden som man kan skicka över protokollet XMPP: Element Tag Types Message <message/> normal, chat, groupchat, headline, error IQ <iq/> get, set, result, error Presence <presence/> Available, unavailable, subscribe, subscribed, unsubscribe, unsubscribed, error 15