CORBA 2.6.1 Programmer's Guide for C++

Addresses
Servers may be configured as direct or indirect TCP servers:
Direct TCP servers are configured with tcp_server true, and the host_name and port_number are specified. These servers communicate
directly with TCP sockets.
Indirect TCP servers are configured with tcp_server true and use_comm_server true. They are accessed by the NSK message system.
Access via TCP will be bridged through a Comm Server. This configuration is useful with stateless servants, and for TCP connection
concentration.
NSDOM_GCF_IOP::Profile_Tag Addresses
If a server is configured to enable GIOP over TS/MP (tsmp_server true), the profile address will contain pathmon-process-name and server-
class.
NSDOM_GFS_IOP::Profile_Tag Addresses
If a server is configured to enable GIOP over the Guardian file system (fs_server true), the address field will contain a Guardian file system
address. If the servant's POA has the PERSISTENT lifespan policy, the profile address will be set to
pname.subdevice. If the servant's POA has
the TRANSIENT lifespan policy, the profile address will be set to
pname:sequence_number.#subdevice. The sequence number allows NS CORBA
to detect if a server process has been restarted. Transient servants are not valid across process restarts.
IOP::TAG_INTERNET_IOP Addresses
If a server is configured to enable IIOP (tcp_server true), this profile is added to IORs generated for objects within that server. NonStop
CORBA supports the IIOP profile defined by the OMG. You can configure TCP servers either as direct or indirect. The content of the
host and
port fields are of interest here.
The address field contains dot-separated IPv4 address like
172.31.41.151 or colon-separated IPv6 address like fe80::a00:8eff:fe06:d093 and
a
port_number. Both, TCP/IP address and port number is dependent on server configuration and servant POA lifespan policy:
If the server is configured as an indirect TCP server, or the servant's POA has a PERSISTENT lifespan policy, these fields will contain
the actual host name and port number of the LSD (see Configured Versus Actual TCP Addresses). The result is that attempts to connect
to such servers will first reach the LSD. The LSD will forward indirect-TCP-server requests to a Comm Server, and direct-TCP-server
requests to the actual TCP address of the server.
If the server is configured as a direct TCP server and the servant’s POA has a TRANSIENT lifespan policy, the host and port fields will
contain the server's actual TCP host name and port number (see
Configured Versus Actual TCP Addresses). Clients' attempts to contact
such a server will connect directly to the server, as opposed to contacting the LSD first.
Configured Versus Actual TCP/IP Addresses and TCP/IPv6 Addresses
When configuring direct TCP servers (that is, tcp_server true, but not use_comm_server), the host_name field can be entered in name-form
rather than the dot-decimal form. Further, since a host name can map to more than one TCP process, the host name might be ambiguous. This
ambiguity is resolved by using the tcp_process entity key in the profile.
Also, the
port_number entity key in the profile can be set to 0, allowing TCP/IP to pick a port as shown in this configuration database record:
cfgmgt> entity xyz_service@ORB
tcp_server true
tcp_process $ztc1
host_name oss2.widget.com
port_number 0
When NonStop CORBA builds an IOP::TAG_INTERNET_IOP profile, the profile's host field must be in dot-decimal form to avoid having to export
the DNS/host-file configuration to every client. Also, the port field must have the actual port number selected by TCP if it was configured as 0.
This arrangement is accomplished by the server writing its actual TCP address to the configuration database upon successfully performing a
socket listen (the listen occurs during the
CORBA::ORB::ORB_init() method invocation). Each time a direct TCP server runs, it generates an
actual_tcp_address entity. This record shows up as <profile>@actual_tcp_address in the configuration database. To continue with the
configuration above, after running the xyz server (and it calls the
CORBA::ORB::ORB_init() method), you would be able to see this record using
cfgmgt:
cfgmgt> entity xyz_service@actual_tcp_address
host_name <change_me>
port_number 1342
Where,
change_me is a dot-separated IPv4 address like 172.31.41.151 or colon-separated IPv6 address like fe80::a00:8eff:fe06:d093.
Each time the xyz server is run, you would expect to see a new xyz_service@actual_tcp_address entity. The host_name would not change, but
since TCP is picking xyz_service's
port_number, that field should have a new value each time.
Interoperable Object References for Objects in a Server Pool