Universal Messaging supports four Native Communication Protocols. These TCP protocols are:

These wire protocols are available for client-to-realm and realm-to-realm connections.

The Universal Messaging Socket Protocol (NSP) is a plain TCP socket protocol optimized for high throughput, low latency, and minimal overhead.

The Universal Messaging SSL (NSPS) Protocol uses SSL sockets to provide the benefits of the Universal Messaging Socket Protocol combined with encrypted communications and strong authentication.

We strongly recommend use of the NSPS protocol in production environments where data security is paramount.

The Universal Messaging HTTP (NHP) Protocol uses a native HTTP stack running over plain TCP sockets, to transparently provide access to Universal Messaging applications running behind single or multiple firewall layers.

This protocol was designed to simplify communication with Realms on private address range (NAT) networks, the Internet, or within another organization's DMZ.

There is no requirement for a web server, proxy, or port redirector on your firewall to take advantage of the flexibility that the Universal Messaging HTTP Protocol offers. The protocol also supports the use of HTTP proxy servers, with or without proxy user authentication.

An nhp interface will also support connections using the nsp protocol. For this reason it is suggested that you use this protocol initially when evaluating Universal Messaging.

The Universal Messaging HTTPS (NHPS) Protocol offers all the benefits of the Universal Messaging HTTP Protocol described above, combined with SSL-encrypted communications and strong authentication.

We strongly recommend use of the Universal Messaging HTTPS Protocol for production-level applications which communicate over the Internet or mobile networks.

We generally recommend that you initially use the Universal Messaging HTTP Protocol (nhp) for Universal Messaging Native clients, as this is the easiest to use and will support both nhp and nsp connections.

When deploying Internet-applications, we recommend using the Universal Messaging HTTPS Protocol (nhps) for its firewall traversal and security features.

When handling many inbound connections that do not require the HTTP or HTTPS protocol, we recommend using the Universal Messaging Socket Protocol (nsp) or the Universal Messaging SSL Protocol (nsps).

The RNAME used by a Native Universal Messaging Client to connect to a Universal Messaging Realm server using a Native Communication Protocol is a non-web-based URL with the following structure:

where <protocol> can be one of the 4 available wire protocol identifiers:

An RNAME string consists of a comma-separated list of RNAMEs.

A Universal Messaging realm can have multiple network interfaces, each supporting any combination of Native and Comet communication protocols.

When a Universal Messaging Native Client connects to a Universal Messaging Realm, it supplies the username of the currently-logged-on user on the client host machine. This username is used in conjunction with the hostname of the realm to create a session credential of the form user@realm.

For example if you are logged on to your client machine as user fred, and you specify an RNAME string of nsp://realmserver.mycompany.com:9000, then your session will be identified as fred@realmserver.mycompany.com.

Note, however, that if you were running the client application on the same machine as the Universal Messaging Realm and decided to use the localhost interface in your RNAME string, you would be identified as fred@localhost - which is a different credential.

The Realm and channel Access Control Lists (ACL) checks will be performed against this credential, so be careful when specifying an RNAME value.