 If I could have your attention, I have seven minutes to present this, so it's a lot of material to cover. I'm Beach Margaret Hindren. This is Weston Sewell. We work at AMD, and we use XMPP in application messaging system. Our problem is we need to easily identify PCs on the network ready for diagnostic runs asynchronously and without blocking, feed them sequences of commands, and robustly capture the streaming output from them, even in the event of network outages, hangs in reboots. This is our architecture. We have a controller and various targets all connected through XMPP. Go ahead. XMPP, at a real high level, it's an XML-based stream architecture using authentication and security in that stream. It was intended to be a grand unified IM system developed in 1998 originally called Jabber became XMPP as it got standardized. It's got libraries in 15 languages plus JavaScript, Ruby, Java, XeSharp, whatever you desire, and it uses a Jabber ID as its token of identification. Here's the real meat of the presentation. There are three useful XML stanzas in XMPP. The message stanza, which is how you send chat messages, is all queued on the server. If you have outages of various components, somebody's offline, it gets queued on the server and will be delivered to them once they're online. All of these are extensible in some way, these stanzas. These have an X element that you can embed in the message stanza that will allow you to define your own XML to embed in the system. The feature that you get out of messages is that they're guaranteed delivery. We use these for the output from the target systems that we want to receive. We don't want to lose that data, and also for the commands that we're sending the target, such that if the targets go offline for a while and come back online, they will get the message and keep going. Presence. Presence is a really magical thing in XMPP. It tells you when some system, XMPP target is online, offline, idle, do not disturb. That sort of thing is what's embodied in presence. Your last presence is cached on the server and is spread via roster information. It also is extendable by the X field, the X tag, and you can then embed extra information. For example, we embed the location of the target system, the friendly name like Bob's server or whatever. It has also got the feature that it can broadcast. It's useful for conditions where in our development environment we have multiple controllers and we want all these business messages to go to those. We use it for metadata about the target. IQ is the third stanza of use in XMPP, and it's not queued at all. It's a request response style stanza. You would say IQ set, and then you would get an IQ response back from that result back or an error. It extends by query. The thing that you can put into an IQ is a query, and you can put your own queries in. You can define your own data that you're transmitting over the wire. We use it for commands we don't want to specifically queue like reboots. We don't want to be able to queue up reboots and have the user press the reboot button and then spontaneously reboot the computer much. We use eJabberD as our server. It is really, really, really solid. We've never, ever had a problem with eJabberD. It is a little weird to configure. I followed that how-to on Ubuntu, and it was very useful. Okay, so here's a hello world. So XMPP4r is really very good. It's a little cumbersome at first. We used XMPP Simple, which was a wrapper around it, but it's not as... After just a minute, we wanted to go deeper into the metal than XMPP Simple did, so we went right to XMPP4r. This is the equivalent of hello world in XMPP. You create your client connection, you connect, you authenticate. If you aren't registered, you should register first. You can also rescue that, so you can handle that case. You set up your initial presence. This is important. You have to tell the XMPP system that you are there. Hello. And then you can send your message. Here is an example of ping. Ping is defined in one of the XEPs, one of the extensions to the protocol. You have to qualify it with the... So in XMPP4r, they provide like an IQ get. So this is creating an IQ get stanza. And you're adding the ping element with the XML namespace of urn, XMPP ping. These are all defined in the spec. You have to do a lot of spec reading. Then you can send that IQ stanza and it goes to the target that you decide to descend it to. And for example, I'm sending a little flag that I sent the message. So everything done in XMPP is handled by callback. So this IQ callback is the callback that's invoked whenever your client receives an IQ message. And it will pass the IQ message that was received into this callback for handling. So we look for a ping element. And if its type is get, that means that somebody is asking us for ping. So we respond and has a nice little method called answer that will just reverse the to field and flip it back. If we get a result back, then we know that the ping was received. And when you get an error, you failed. Putting the X and XMPP, this is how you do an extension. So we just extend from Jabber X, add the location. That's the stanza that's generated from that. So that's how you send it. You just create the extension, add the location, send, receiving side. You just filter the by m.x, the namespace. And that will filter it, okay, quick. Tips and tricks, be sure to send initial presents, promiscuously accept roster subscriptions so that people can know when you're online. Turn on the debugger, it's very useful. Choose your message types next. Good things, next. Many things, yes. Things you can do better. We had the XMPP server message, the controller subscribed to new targets. That's not really brilliant. Okay, my time's up. Knees saved server. And occasionally, the XMPP server takes an hour to recognize the target is offline, like when it powers off unexpectedly. If anybody knows how to solve that, I'd appreciate it, thanks.