Networking

Summarized using AI

XMPP and Application Messaging

Bheeshmar Redheendran and Weston Sewell • August 27, 2009 • Earth

The video titled "XMPP and Application Messaging," presented by Bheeshmar Redheendran and Weston Sewell at the LoneStarRuby Conf 2009, focuses on the use of XMPP (Extensible Messaging and Presence Protocol) in their application messaging system at AMD. The presentation outlines the challenges of identifying PCs on a network for asynchronous diagnostic runs, where the system needs to send commands and capture streaming output reliably, despite potential network issues.

Key points discussed include:
- Introduction to XMPP: An XML-based stream architecture designed for secure and authenticated messaging, initially developed in 1998 as Jabber and later standardized as XMPP. It offers libraries in multiple programming languages, such as JavaScript, Ruby, and Java.
- Types of XMPP Stanzas:
- Message Stanza: Used for chat messages and boasts guaranteed delivery. It's ideal for sending commands and receiving outputs from target systems, ensuring no data loss during outages.
- Presence Stanza: Provides status updates on targets (online, offline, do not disturb) and allows for extensibility, such as embedding additional information like location.
- IQ Stanza: A request-response based stanza that avoids queuing and is used for commands such as reboots, which need immediate processing.
- XMPP Server Utilization: The presenters use eJabberd for their server needs, noting its reliability despite a steeper learning curve for configuration.
- Client Connection and Messaging: They demonstrate a basic client connection using xmpp4r, including setting initial presence and processing IQ stanzas. The importance of callbacks for handling messages is emphasized.
- Extensions and Best Practices: The presenters discuss extending the protocol, managing initial presence broadcasts, and the significance of debugging tools. They also highlight a potential issue with servers not promptly recognizing offline targets and invite feedback on this matter.

In conclusion, the presentation emphasizes the effectiveness of XMPP in building a robust messaging system for application diagnostics, ensuring reliable communication even in challenging network environments. The presenters encourage onlookers to leverage these insights and best practices in their own projects, while also fostering a dialogue for resolving XMPP server-related challenges.

XMPP and Application Messaging
Bheeshmar Redheendran and Weston Sewell • August 27, 2009 • Earth

XMPP and Application Messaging by: Bheeshmar Redheendran, Weston Sewell

Help us caption & translate this video!

http://amara.org/v/G1XA/

LoneStarRuby Conf 2009

00:00:20.939 If I could have your attention, I have seven minutes to present this, so it's a lot of material to cover. We're Bheeshmar Redheendran and Weston Sewell, and we work at AMD. We use XMPP in our application messaging system. Our problem is that we need to easily identify PCs on the network that are ready for diagnostic runs asynchronously and without blocking. We need to feed them sequences of commands and robustly capture the streaming output from them, even in the event of network outages, hangs, and reboots.
00:00:32.460 This is our architecture: we have a controller and various targets, all connected through XMPP. At a high level, XMPP is an XML-based stream architecture that uses authentication and security in that stream. It was intended to be a grand unified instant messaging system developed in 1998, originally called Jabber. It became XMPP as it was standardized. It has libraries in 15 different languages, including JavaScript, Ruby, Java, C#, and others. It uses a Jabber ID as its token of identification.
00:01:09.960 Now, here's the real meat of the presentation: there are three useful XMPP stanzas. The message stanza is how you send chat messages, and it is all queued on the server. If you have outages of various components or someone is offline, the messages get queued on the server and will be delivered to them once they're online. All of these stanzas are extensible in some way. They have an 'X' element that you can embed in the message stanza, allowing you to define your own XML to include in the system. The feature you get from messages is guaranteed delivery. We use these for the output from the target systems that we want to receive because we do not want to lose that data, as well as for the commands that we're sending to the targets.
00:02:05.939 For instance, if the targets go offline for a while and then come back online, they will get the message and keep going. The presence stanza in XMPP is truly magical. It tells you when some XMPP target is online, offline, idle, or in 'do not disturb' mode. This information is cached on the server and distributed via roster information. It is also extendable using the 'X' tag, allowing you to embed extra information. For example, we embed the location of the target system and a friendly name like 'Bob's server.' Presence can also broadcast, which is useful in our development environment where we have multiple controllers and want all the busy messages to be sent to those controllers.
00:02:54.840 The IQ stanza is the third type of stanza used in XMPP. It's not queued at all; it's a request-response style stanza. You would say 'IQ set,' and then you would receive an IQ response back, or an error. The thing you can include in an IQ is a query, so you can define your own data that you're transmitting over the wire. We use it for commands that we don't want to specifically queue, such as reboots. We don't want users to queue up reboots and, after pressing the reboot button, spontaneously reboot the computer.
00:03:49.140 We use eJabberd as our server. It is really solid; we've never had a problem with its reliability. However, it is a little strange to configure, but I found a useful how-to guide on Ubuntu. So here’s a simple example: xmpp4r is quite powerful. Initially, we used XMPP Simple, which was a wrapper around xmpp4r, but we found it lacked depth. We wanted to go deeper into the metal than XMPP Simple provided, so we switched to xmpp4r. This demonstrates the equivalent of 'Hello, world!' in XMPP: you create your client connection, connect, and authenticate. If you aren't registered, you should register first. You can also handle that case.
00:04:11.959 You then set up your initial presence. This is important; you have to tell the XMPP system that you are there. After that, you can send your message. For example, ping is defined in one of the XEPs, which are extensions to the protocol. You have to qualify it, so in XMPP4R they provide an IQ 'get' functionality. This creates an IQ 'get' stanza where you add the ping element with the correct XML namespace, as defined in the spec. Sending IQ stanzas involves a lot of reading of the specification.
00:05:03.600 You can then send that IQ stanza to the target you want to communicate with. For instance, I’m sending a flag to indicate that I sent the message. Everything in XMPP is handled by callbacks. When your client receives an IQ message, it will invoke the corresponding callback and pass the IQ message received into it for handling. We look for a ping element, and if its type is 'get,' that means somebody is asking us to respond to the ping. We respond using a method called 'answer' that reverses the two fields and sends it back. If we get a result back, we know the ping was received, and if there's an error, it means we failed to process the request.
00:06:14.880 This demonstrates how to handle an extension in XMPP: we extend from Jabber, adding the location as the stanza that gets generated. On the receiving side, we filter by the XML namespace 'm.x,' which helps in filtering the relevant messages.
00:06:43.740 Now, here are some quick tips and tricks: be sure to send initial presence promiscuously and accept roster subscriptions, so others can know when you’re online. Turn on the debugger; it's invaluable. Choose your message types wisely. While there are good aspects of XMPP, there are also setbacks. One issue we encounter is when the XMPP server takes an unusually long time to recognize a target as offline after an unexpected power off. If anyone has suggestions for resolving that, I would greatly appreciate it. Thank you.
Explore all talks recorded at LoneStarRuby Conf 2009
+14