CommuniGate Pro
Version 5.3
Real-Time
 
 
XMPP

XMPP Module

The CommuniGate Pro XMPP Module implements the XMPP protocol via TCP/IP networks.

The XMPP module implements the client-server XMPP protocol. The module allows end-user applications (XMPP clients) to log into the CommuniGate Pro Server and to execute Real-Time Signal operations.

The XMPP module implements the server-server XMPP protocol. The module allows the remote XMPP systems (remote servers) to connect to the CommuniGate Pro Server, and it allows the CommuniGate Pro Server to connect to the remote XMPP systems, so they can exchange Real-Time Signal requests and responses.

The module implements the basic XMPP protocol and its extensions (XEPs).

Extensible Messaging and Presence Protocol (XMPP)

The CommuniGate Pro XMPP Module implements the XMPP protocol functionality. It uses one TCP Listener for both client-server and server-server connections, distinguishing them not by the port number the remote side connects to, but by the XML data trasnferred.
By default, the XMPP Module TCP Listener uses the plain-text ports 5222 and 5269 and the secure (TLS) port 5223.

When a client-server connection is established, the XMPP module authenticates a user, and creates a session for the user Account. It then sends the Real-Time Signals on that Account behalf.

When a server-server connection is established, the XMPP module receives XMPP requests, converts them into internal Real-Time Signals, and submits them to the Real-Time component for processing and further delivery. It also receives the Signals directed to it by the Real-Time component and delivers them to remote XMPP systems.

The XMPP Module maintains a separate queue for each target and source domain, i.e. there are different queues for requests to the target.dom Domain coming from addresses in the source1.dom and source2.dom domains.
The XMPP module tries to open a new TCP/IP connection for each queue. If a connection is estblished, it sends all enqueued requests (as XMPP XML stanzas). When all enqueued requests are sent, the module keeps the connection open waiting for new requests to be sent to this queue. If the connection stays idle for the specified period of time, the XMPP module closes it.

The XMPP message requests are sent as MESSAGE Real-Time requests, the XMPP presence requests are sent as SUBSCRIBE and NOTIFY Real-Time requests (using the presence Event package), the XMPP iq requests are sent as INFO Real-Time requests.
The XMPP request data beyond the basic information is sent as the P-XMPP-Data field data.


XMPP Server Settings

Use the WebAdmin Interface to configure the XMPP module. Open the Real-Time pages page in the Settings realm, then open the XMPP pages.
Click the Receiving link to open the XMPP Server Settings.

Processing
Log Level: Listener Channels:

Use the Log Level setting to specify what kind of information the XMPP module should put in the Server Log. Usually you should use the Major (message transfer reports) or Problems (message transfer and non-fatal errors) levels. But when you experience problems with the XMPP module, you may want to set the Log Level setting to Low-Level or All Info: in this case protocol-level or link-level details will be recorded in the System Log as well. When the problem is solved, set the Log Level setting to its regular value, otherwise your System Log files will grow in size very quickly.

The XMPP server records in the System Log are marked with the XMPPI tag.
If the remote party specifies that the connection is used for a client session (as opposed to server-to-server transfer), the System Log tag is changed to XMPPS.

System Log records for outgoing server-to-server XMPP connections are marked with the XMPPO tag.

When you specify a non-zero value for the Channels setting, the XMPP module creates a TCP listener, and the module starts to accept XMPP connections from client applications and remote servers.
The setting is used to limit the number of simultaneous connections the XMPP module can accept. If there are too many incoming connections open, the module will reject new connections, and client applications and remote servers should retry later.

By default, the XMPP module Listener accepts clear text connections on the TCP port 5222 ("client port") and 5269 ("server port") and secure TLS connections on the TCP port 5223 ("secure client port").
Follow the listener link to tune the XMPP Listener.

The XMPP module supports the starttls command; it allows client applications and remote servers to establish a connection in the clear text mode and then turn it into a secure connection.

The XMPP module supports all available SASL authentication methods. Additionally, the module supports the legacy Jabber authentication - plain text "password" and "digest".
To disable the "digest" Jabber authentication method, you need to disable the CRAM-MD5 method for the target Domain.


XMPP Client Settings

Use the WebAdmin Interface to configure the XMPP module. Open the Real-Time pages page in the Settings realm, then open the XMPP pages.
Click the Sending link to open the XMPP Client Settings.

Processing
Log Level: Idle Timeout:
Log Level
This is the same setting as seen on the XMPP Server Settings page.
Idle Timeout
Use this setting to specify how long the XMPP module should keep an outgoing connection open if it has no data to be sent to a remote server.

Monitoring XMPP Activity

The Monitors realm of the WebAdmin Interface allows Server Adminstrators to monitor the XMPP module activity.

Click the Real-time link in the Monitors realm to open the XMPP Monitoring page. This page has the same format as the IMAP Monitoring WebAdmin page.


Registration

The XMPP module implements the XEP-0077 extension (registration and password changes).

The Auto Signup option allows users to 'register' (to create Accounts for themselves).

If the Allow to Modify Password option is enabled, the users can modify their passwords themselves.


Chat Rooms

The XEP-0045 extension (Multi-User Chat) is implemented outside the XMPP module itself, using the CG/PL chatroom Named Task.

The Named Task is started automatically when the first user tries to access it. The Named Task receives all Instant Message and Presence requests sent to it from various clients (XMPP, XIMSS, other Tasks, etc.), and dsitrbutes these Signal requests to the room participants.


CommuniGate® Pro Guide. Copyright © 1998-2010, Stalker Software, Inc.