Universal Messaging 9.8 | Universal Messaging 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
Adobe Flex
yes
yes
yes
yes
N/A
N/A
N/A
Microsoft Silverlight
yes
yes
yes
yes
N/A
N/A
N/A
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
*<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 in order traversal of RNAME values while using a semicolon-separated list indicates random traversal of RNAME values.
If a list of RNAMEs is used and the Universal Messaging session becomes disconnected and cannot reconnect, the API will cascade 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 said 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.

Copyright © 2013-2015 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.