CORBA 2.6.1 Administration Guide

configuration database identifies the transport protocols used by the server. Some CORBA servers place information into the configuration
database. For example, the naming service stores the root naming context object reference into the configuration database. The configuration
database enables NonStop CORBA 2.6.1 to use implementation-specific data. Since these data are obtained from a database instead of
appearing in the server code, the servers can be portable.
Comm Server
The Comm server is a component of NonStop CORBA 2.6.1 that provides connectivity to applications for network clients. These clients obtain
the benefits of the Comm server without any special programming. CORBA requests and responses may be routed through the Comm server
based on information contained in the interoperable object reference used by the client. The Comm server provides two benefits:
It acts as a gateway to facilitate communication between network clients and application servers on the NonStop CORBA system.
It acts as a network resource concentrator thus enabling construction of large-scale servers.
As a gateway, the Comm server enables network clients to interact with NonStop CORBA servers. In some cases the servers do not directly
support the IIOP protocol that network clients must use. This is true in the case of servers hosting stateless objects. Each request to a stateless
object may be routed to a different server-pool process. Here the Comm server is used to interact with the TS/MP facility to perform the routing.
Without the Comm server, network clients could not make use of these stateless objects.
As a network resource concentrator, the Comm Server makes efficient use of network resources. For large-scale systems having many CORBA
clients and servers, the Comm server manages network communications between network clients and NonStop CORBA servers, thus reducing
the demand for TCP/IP ports (a potentially scarce resource on the system). A single Comm Server process may handle many network clients
simultaneously; however, depending on needs of your system, multiple Comm servers can be configured. Using multiple Comm Servers allows
larger volumes of traffic to be handled because the load is spread across multiple processors.
Parallel Library TCP/IP
Another way to increase capacity and fault tolerance is to configure the IIOP connectivity components of your system (Comm Server, LSD,
ILSD, and BSD processes) to use Parallel Library TCP/IP. With this configuration, multiple Comm Server processes running in a pool can share
the same port. A round-robin filter distributes the incoming connections among the Comm Server pool. When configured this way the Comm
Server pool appears as a single IP host to the outside world.
Figure 1–7 shows the original way of configuring TCP/IP in a NonStop system. Note:
There is one Comm Server per port, limiting throughput on that port.
There is a TCP/IP process between the ServerNet adapter and a Comm Server, requiring a message system hop.
Figure 1.3. Original TCP/IP
Each Fast Ethernet ServerNet Adapter (FESA) corresponds to a TCP/IP port.
By comparison, configuring the IIOP connectivity components of your system to use Parallel Library TCP/IP allows publishing a single port for
up to 16 Comm Server processes. Message system hops are reduced by moving execution of TCP data-path functions from the TCP/IP process
into the user process (Comm Server in this case), referencing the Parallel Library TCP/IP SRL.
Figure 1.4. Parallel Library TCP/IP