Universal Messaging 10.5 | Concepts | Architecture | Communication Protocols and RNAMEs
 
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
yes
yes
yes
yes
yes
N/A
N/A
C# .NET
yes
yes
yes
yes
N/A
N/A
N/A
C++
yes
yes
yes
yes
yes
N/A
N/A
Python
yes
yes
yes
yes
N/A
N/A
N/A
Excel VBA
yes
yes
yes
yes
N/A
N/A
N/A
JavaScript
N/A
N/A
yes via WebSocket
yes via WebSocket
N/A
yes
yes
iPhone
yes
yes
yes
yes
N/A
N/A
N/A
Android
yes
yes
yes
yes
N/A
N/A
N/A
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 the following extension 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.