Another progress report

I improved the handling of HTTP connections in my implementation. It now supports non-persistent connections to ejabberd and keep-alive and pipelining connections to Openfire (using Safa's dev build). I also implemented acknowledgments checking and key-sequencing. Additionally, I made some modifications to the proxy group stored in the Gajim config file. The configuration dialog for BOSH proxy has slightly changed to allow an optional set of HTTP proxy before the Connection Manager.

Next, I will focus on securing BOSH TCP connections. Currently, Gajim attempts to establish an SSL connection first and falls back to plain text when SSL negotiation or handshake fails. When connecting to the Connection Manager via BOSH, there shouldn't be an issue as long as the client goes directly to CM. The protocol used (XMPP or HTTP) over SSL doesn't matter in this case, although there is no negotiation within BOSH. However, when a proxy is used, I observed that Firefox sends an HTTP request with the CONNECT method to the proxy, which opens a tunnel to the remote machine. The SSL handshake then occurs on the opened channel. I will adopt the same approach because there seems to be no other way to tunnel HTTPS over a proxy.

With the tunnel established using CONNECT, it would be more reasonable to send XMPP directly instead of using BOSH over HTTP. However, CONNECT is usually limited to certain port numbers. Nonetheless, I believe it should be possible to achieve the same with BOSH as well (Gajim already supports XMPP via HTTP proxy using the CONNECT method).

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.

• Openfire - XEP-0124 listed in supported XEPs.
  
• ejabberd - Release notes for version 2.0.0 mention XEP-0124 support. Offers SASL mechanisms in initial response, so XEP-0206 is supported as well.
  
• Tigase Server - BOSH support since 3.0.2
  

Standalone Connection Managers
Act as a proxy between client and XMMP server.

• Araneo - Minimal CM written in Python using Twisted. I found the link on MattJ's blog
  
• Punjab - Python and Twisted again.
• rhb - CM in Ruby.
  
• JabberHTTPBind - Java servlet implementing XEP-0124.
  

Clients

• JWChat - full featured JavaScript client. Needs CM to operate, uses JSJaC library.
• soashable
  

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.

First steps

I'm providing a summary of my progress in the first six days of GSoC coding. Throughout the coding period, I plan to publish a blog post every weekend to document my journey.

My project focuses on expanding the functionality of the Gajim jabber client. To begin, I delved into understanding the existing code responsible for XMPP communication. Gajim utilizes a modified version of the xmpppy library, which includes non-blocking transports with callbacks and message queues to notify connected objects at regular intervals. The Gajim architecture involves three relevant layers: the Connection class, acting as the interface between the UI and xmpppy (one instance per jabber account); the Client class, responsible for establishing the connection to the XMPP server and handling authentication; and the transport classes that format data for different protocols (SSL, TLS, TCP, HTTP proxy, SOCKS5 proxy). The transports themselves are not aware of XMPP stanzas.

In the case of BOSH (Bidirectional-streams Over Synchronous HTTP) messages, XMPP messages are wrapped within a body tag containing BOSH-related attributes. These messages are sent to an HTTP server or proxy known as the Connection Manager, instead of directly to the XMPP server. The communication scheme differs slightly to allow for server-initiated requests in HTTP (refer to XEP-0124). Based on this understanding, I determined the starting point for my coding efforts. Considering the variation in stream initiation between XMPP over BOSH and plain XMPP, I decided to create a BOSHClient class derived from NBCommonClient. In the existing code, the Connection object holds an instance of NonBlockingClient, also derived from NBCommonClient, as shown in the class diagram.

The plan is to utilize the BOSHClient instead of NonBlockingClient for accounts connecting to the BOSH Connection Manager. Currently, I have successfully built and sent the initial request, received and parsed the response, albeit with limited error checking. My next steps involve integrating the Gajim module for SASL authentication and subsequently sending the first message via BOSH.