Communication Protocols and RNAMEs
Universal Messaging supports several Native Communication Protocols (see
Native Communication Protocols) and Comet Communication Protocols (see
Comet Communication Protocols).
The following table shows the Communication Protocols supported by each Universal Messaging Client API:
| Native Communication Protocols | Comet Communication Protocols |
| Socket (nsp) | SSL (nsps) | HTTP (nhp) | HTTPS (nhps) | Shared Memory (shm) | HTTPS (https) | HTTP (http) |
Java | | | | | | | |
C# .NET | | | | | | | |
C++ | | | | | | | |
Python | | | | | | | |
Excel VBA | | | | | | | |
JavaScript | | |  via WebSocket | via WebSocket | | | |
Adobe Flex | | | | | | | |
Microsoft Silverlight | | | | | | | |
iPhone | | | | | | | |
Android | | | | | | | |
RNAMEs
An RNAME is used by Universal Messaging Clients to specify how a connection should be made to a Universal Messaging Realm Server.
A Native Communication Protocol (see
Native Communication Protocols) RNAME string looks like:
<protocol> :// <hostname> :< port>,<protocol> :// <hostname> :< port>
or
<protocol> :// <hostname> :< port>;<protocol> :// <hostname> :< port>
where:
<protocol> can be one of the 4 available native communications protocol identifiers nsp (socket), nhp (HTTP), nsps (SSL) and nhps(HTTPS).
<hostname> is the hostname or IP address that the Universal Messaging Realm is running on.
<port> is the TCP port on that hostname that the Universal Messaging Realm is bound to using the same wire protocol.
The RNAME entry can contain a comma or semicolon separated list of values, each one representing the communications protocol, host and port currently running on a Universal Messaging Realm.
Using a comma-separated list indicates the traversal of the RNAME values in the order given, while using a semicolon-separated list indicates the random traversal of the RNAME values.
If a list of RNAMEs is used and the Universal Messaging session becomes disconnected and cannot reconnect, the API will traverse through the RNAME list until it manages to reconnect. This functionality is particularly useful within the contexts of both clustering (see
Clusters: An Overview) and failover (see
Failover).
Native Communications Protocol Client Extensions
In addition to the supported protocols shown above, Universal Messaging clients implemented with APIs that support Native Communication Protocols have a number of extensions available to them:
nhpsc This mode of https extracts any configured proxy from within the JVM settings and issues a PROXY CONNECT command via this proxy to establish a connection with the required Universal Messaging realm. The established connection then becomes an SSL encrypted socket connection mode and no longer uses http/https connections for each server request. If the proxy uses authentication then authentication parameters are also extracted from the JVM settings.
nhpm and nhpsm Up to and including Universal Messaging 6.x, nhpm and nhpsm were multiplexed versions of the standard http and https protocols. The key difference is that any sessions established using a multiplexed RNAME only ever establish one connection to the Universal Messaging realm server. This is very useful for circumventing browser connection limits while supporting multiple sessions.
Note: Please note that since Universal Messaging 7, nhpm and nhpsm protocols are no longer used since multiplexed sessions are supported using any protocol.
