Nirvana Native Communication Protocols
Nirvana supports four Native Communication Protocols. These TCP protocols are:
- Nirvana Socket Protocol (nsp)
- Nirvana SSL Protocol (nsps)
- Nirvana HTTP Protocol (nhp)
- Nirvana HTTPS Protocol (nhps)
Nirvana Socket Protocol (nsp)
The Nirvana Socket Protocol (NSP) is a plain TCP socket protocol optimized for high throughput, low latency and minimal overhead.
Nirvana Socket Protocol (nsp)
Nirvana SSL Protocol (nsps)
The Nirvana SSL (NSPS) Protocol uses SSL sockets to provide the benefits of the Nirvana 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.
Nirvana SSL Protocol (nsps)
Nirvana HTTP Protocol (nhp)
The Nirvana HTTP (NHP) Protocol uses a native HTTP stack running over plain TCP sockets, to transparently provide access to Nirvana 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, servlet engine or port redirector on your firewall to take advantage of the flexibility that the Nirvana 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 Nirvana.
Nirvana HTTP Protocol (nhp)
Nirvana HTTPS Protocol (nhps)
The Nirvana HTTPS (NHPS) Protocol offers all the benefits of the Nirvana HTTP Protocol described above, combined with SSL-encrypted communications and strong authentication.
We strongly recommend use of the Nirvana HTTPS Protocol protocol for production-level applications which communicate over the Internet or mobile networks.
Nirvana HTTPS Protocol (nhps)
Recommendation
We generally recommend that you initially use the Nirvana HTTP Protocol (nhp) for Nirvana Native clients, as this is the easiest to use and will support both nhp and nsp connections.
When deploying Internet-applications, we recommend the Nirvana HTTPS Protocol (nhps) for its firewall traversal and security features.
RNAMEs
The RNAME used by a Native Nirvana Client to connect to a Nirvana Realm server using a Native Communication Protocol is a non-web-based URL with the following structure:
<protocol>://<hostname>:<port>
where <protocol> can be one of the 4 available wire protocol identifiers:
- nsp (Nirvana Socket Protocol),
- nsps (Nirvana SSL Protocol),
- nhp (Nirvana HTTP Protocol) or
- nhps (Nirvana HTTPS Protocol)
An RNAME string consists of a comma-separated list of RNAMEs.
A Nirvana realm can have multiple network interfaces, each supporting any combination of Native and Comet communication protocols.
User@Realm Identification
When a Nirvana Native Client connects to a Nirvana 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://realm.my-channels.com:9000, then your session will be identified as fred@realm.my-channels.com.
Note, however, that if you were running the client application on the same machine as the Nirvana 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.
