HTML and CSS Reference
http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01 . Alternatively,
at the time of the writing of this topic, there are a few experimental modules:
ejabberd-websockets and Openfire's module with WebSocket support. Figure 4-3
illustrates a client connecting to a WebSocket-enabled XMPP server.
Figure 4-3. Connecting to a WebSocket-aware XMPP server
The second approach is to use a proxy server that accepts WebSocket connections
from clients and makes corresponding TCP connections to back-end servers. In this case,
the back-end servers are standard XMPP servers that accept XMPP over TCP connections.
XmppClient in the Kaazing WebSocket Gateway takes this gateway approach. Here,
applications can connect through Kaazing's gateway to any XMPP server, even servers
that have no explicit support for WebSocket. Figure 4-4 shows an example of a WebSocket
gateway server accepting WebSocket connections and making corresponding TCP
connections to a back-end XMPP server.
Figure 4-4. Connecting to an XMPP server through a WebSocket proxy
When choosing your connectivity strategy, it is important to understand how WebSocket
messages (which typically comprise a single WebSocket frame) are aligned to XMPP
stanzas, as the two approaches differ. In the case of WebSocket-aware XMPP servers,
stanzas are mapped one-to-one onto WebSocket messages. Each WebSocket message
contains exactly one stanza, and there can be no overlap or fragmentation. The draft
XMPP for WebSocket subprotocol specifies this alignment. Stanza-to-message alignment
is not necessary in the gateway scenario, because it is relaying WebSocket to TCP and
vice versa. TCP does not have message boundaries, so the TCP stream might be split
arbitrarily into WebSocket messages. In the gateway case, however, the client must be