Sunday, June 15, 2008

Third week of GSoC

In the past two weeks, I realized that the design I proposed in my previous post was flawed. The socket wrapper in xmpppy doesn't allow for multiple wrappers per client, and it has unnecessary functionalities for the TCP connection object. Therefore, I am currently refactoring the NonBlockingTcp and NonBlockingClient classes in xmpppy. My next step will be implementing a BOSHTransport that can be plugged into the client just like the socket wrapper. Please note that this is still subject to change, so I will provide a class diagram next week.

In the meantime, I have created a unit testing template for NonBlockingClient. I have also set up openfire, punjab, and araneo on my virtual server for testing purposes, and jwchat on localhost for traffic analysis.

You may have noticed my posts appearing multiple times on planet jabber. This is because whenever I edit a post, Blogger updates the <updated> tag in the feed, and the planet reader sorts entries based on the update time instead of the original publication time. Unfortunately, I haven't found a way to ignore entry updates in the planet reader or exclude the update time from the Blogger feed. I am considering moving to Wordpress, as it allows for importing the blog from Blogger, or finding a way to manipulate the feed on my own. Until then, I won't be able to maintain information in my posts or fix any typos.

For a comprehensive list of XMPP software that supports BOSH, you can now visit the jabber.org wiki. I noticed a few more tigase projects on the list that I wasn't aware of, which is pretty cool.

Sunday, June 1, 2008

BOSH in XMPP software

I researched existing HTTP Binding implementations for testing my code with different servers and Connection Managers. BOSH, described in XEP-0124 and XEP-0206, provides mechanisms for reliable XML stream transfer over HTTP. XEP-0124 covers general syntax and error handling, while XEP-0206 addresses session negotiation, error processing, and SASL authentication for XMPP.

In the BOSH architecture, there are clients, servers, and Connection Managers. Clients communicate with the Connection Manager (CM) through HTTP POST requests/responses defined in the mentioned XEPs. The CM, acting as an XMPP client or using the component protocol, communicates with the XMPP server. The CM can be a standalone HTTP server or a built-in feature/extension of an XMPP server. To connect to an XMPP server via BOSH CM, you need the CM URL and port number in addition to the XMPP server address and port. If using built-in Connection Managers, the IP addresses of the XMPP server and CM will be the same, differing only in port numbers.

Here's an overview of XMPP software with BOSH support:


Servers
Servers with built-in Connection Manager.

Standalone Connection Managers
Act as a proxy between client and XMMP server.
Clients
Libraries
  • gloox (C++) - BOSH support done by MattJ during GSoC 2007. BOSH Connection classes are included in svn trunk and 1.0-beta2 (download page).
  • xmpp4r (Ruby)
  • xmpp4js (JavaScript)
  • JSJaC (JavaScript)
  • emite (Google Web Toolkit, Java) - XMPP library and client GUI for gwt, connecting through BOSH Connection Manager.

While I haven't tested all the listed software, I'll continue updating this overview during the summer as I progress with testing. For further reading, refer to MattJ's blog post.