# -ORBEndpoint Details

- Overview
- Endpoint-Specific Options
- Common Endpoint-Specific Options
- IIOP Endpoints
- SHMIOP Endpoints
- UIOP Endpoints
- DIOP Endpoints
- SSLIOP Endpoints

## Overview

Tells the ORB to listen for requests on the interface specified by endpoint. Endpoints are specified using a URL style format. An endpoint has the form:

> `protocol://V.v@addr1,...,W.w@addrN`

where `V.v` and `W.w` are optional protcol versions for each address. An example of an IIOP endpoint is:

> `iiop://hostname:port`

Sets of endpoints may be specified using multiple `-ORBEndpoint` options or by delimiting endpoints with a semi-colon (;). For example:

> `-ORBEndpoint iiop://localhost:9999 -ORBEndpoint uiop:///tmp/mylocalsock -ORBEndpoint shmiop://10002`

is equivalent to:

> `-ORBEndpoint 'iiop://localhost:9999;uiop:///tmp/mylocalsock;shmiop://10002'`

Notice the single quotes (') in the latter option specification. Single quotes are needed to prevent the shell from interpreting text after the semi-colon as another command to run.

If an endpoint is specified without an `addr` such as the following:

> `-ORBEndpoint uiop:// -ORBEndpoint shmiop://`

then a default endpoint will be created for the specified protocol.

This is a server side option.

## Endpoint-Specific Options

The `-ORBEndpoint` options can accept endpoint-specific options. Specifically, such options will only apply to the endpoint for which they were specified.

An endpoint-specific option is used as follows:

> `-ORBEndpoint iiop://foo:1234/option=value`

Additional options can be specified by separating each option with an ampersand '`&`' as follows:

> `-ORBEndpoint 'iiop://foo:1234/option1=value1&option2=value2'`

Notice that the address and the endpoint-specific options are separated by a forward slash '`/`' in this case, i.e. for IIOP endpoints. This character may differ for other types of pluggable protocol endpoints. For example, UIOP endpoint-specifc options are separated from the address by a vertical bar '`|`'. Also note that when using more than option, quotes should be used to prevent the shell from interpreting the ampersand '`&`' as a command to tell the shell to backgroup a job.

## IIOP Endpoints

TAO's IIOP pluggable protocol utilizes TCP/IP as its underlying transport mechanism.

### IIOP Endpoint Overview

IIOP endpoints in TAO have the form:

> `-ORBEndpoint iiop://V.v@hostname1:port1,...,W.w@hostname2:port2`

Where "`V.v`" and "`W.w`" are the IIOP protocol versions associated with the given address (hostname:port pair). Currently supported versions are `1.0`, `1.1`, and `1.2`.

Options are separated from the addresses by a forward slash '`/`'. For instance, if an IIOP endpoint should have a property foobar of 50 associated with it, then the following endpoint specification could be used

> `-ORBEndpoint iiop://hostname:port/foobar=50`

### IIOP Address Format

IIOP addresses are comprised of a hostname (or an IP address) and a TCP port the server should listen on. The hostname is used to select which network interface to set up the endpoint on. It is not used to set the hostname that goes into the generated IOR. This is especially useful if the endpoint should be setup on a specific network interface other than the default network interface.

Suppose a host has the following network interfaces:

- eth0: foo1.bar.baz (DEFAULT)
- eth1: foo2.bar.baz

To set up an endpoint on the second network interface "eth1," the following endpoint specification could be used:

> `-ORBEndpoint iiop://foo2`

or:

> `-ORBEndpoint iiop://foo2.bar.baz`

TAO will attempt to ensure that the fully qualified domain name is embedded in the IOR.

In the above example, an available port will be chosen by TAO (actually the operating system kernel), which will then be placed into the IOR.

To set up an endpoint on a specific port, simply use an endpoint of the form:

> `-ORBEndpoint iiop://foo2:1234`

where `1234` is the TCP port the endpoint will be opened on. In this case, an endpoint will be opened on the network interface associated with the hostname `foo1` on port `1234`.

Port names are also accepted. For example, suppose a UNIX installation has a service called "my_protocol" associated with port 1234 in the service database in `/etc/services`, then the following would cause an endpoint to be opened on the port associated with that service:

> `-ORBEndpoint iiop://foo2:my_protocol`

Port numbers range from `0` (causes port to be chosen by operating system) to `65335`. Port numbers less than `1024` on UNIX systems are considered privileged, and require super-user privileges to access them. Also be aware that some ports may already be in use by other applications.

Suppose an endpoint should be created on each network interface. To do so, simply omit the address from the endpoint specification as follows:

> `-ORBEndpoint iiop://`

In this case, an endpoint will be set up on each network interface detected by TAO. The port for each opened endpoint will be chosen automatically. The chosen port will be the same for all endpoints. Each endpoint will be represented in generated IOR as a separate profile, or as an alternate address within a single IOR profile (once IIOP 1.2 is supported).

Note that network interface detection only work on platforms that support this feature. If network interface detection isn't supported, then the default network interface will be chosen.

Now suppose that an endpoint should be created on each detected network interface, but with a specific port. This can be achieved by using an endpoint specification of the form:

> `-ORBEndpoint iiop://:1234`

This will create endpoints on each detected network interface, each with the TCP port `1234`. Notice that there is a colon '`:`' preceeding the port number `1234`. That colon is necessary to make TAO interpret `1234` as a port. Without the colon, TAO would interpret `1234` as a hostname associated with a given network interface.

### IIOP Endpoint-Specific Options

TAO supports the following endpoint-specific options that apply only to IIOP endpoints:

Option | Availability | Description
--- | --- | ---
`portspan` | `TAO 1.1.15` | The `portspan` option specifies that an IIOP endpoint should be opened on the first available port within a specified span of port numbers, beginning with a specified initial port. This option is useful when one or more servers may be restricted to using ports within a given range. The intention is that the behavior should be similar to using ephemeral ports except within a restricted user-defined range. The format for `ORBEndpoint` with the `portspan` option is: `-ORBEndpoint iiop://[`hostname`]:`initialPort`/portspan=`span where initialPort is the initial port number in the range of allowable ports, and span is an integer value indicating the size of the span of allowable ports. Valid values for initialPort include any valid port number. Valid values for span are in the range `1` to `65535`. The hostname (in `[ ]`)is optional. The server's ORB will attempt to create a listening endpoint beginning with the initial port. If that fails, it will try the next port in the range. It will continue to try each port in the range until it is able to successfully open one for listening or until it has exhausted the range `[initialPort:initialPort+span-1]` at which point it fails with a `CORBA::BAD_PARAM` system exception.
`hostname_in_ior` | `TAO 1.2.4` | The `hostname_in_ior` option allows one to specify the hostname that is inserted into the generated IOR. This option overrides the default (local) hostnames that TAO normally inserts. This can be useful in environments where the hostname in use is one whose IP address changes dynamically. The format for `ORBEndpoint` with the `hostname_in_ior` option is: `-ORBEndpoint iiop://[`local_hostname`]:`port`/hostname_in_ior=`overridden_hostname where local_hostname and port are specified as normal, and overridden_hostname is the hostname that should be put into generated IORs.

### IIOP Endpoint Examples

Here are some additional examples of IIOP endoints:

- `-ORBEndpoint iiop://1.0@foo1:0`
- `-ORBEndpoint iiop://1.0@foo:0,1.1@bar,baz:3456`
- `-ORBEndpoint iiop://1.0@foo:0,1.1@bar,baz:3456/foobar=300`
- `-ORBEndpoint iiop:///foobar=2` (notice three slashes "`///`")
- `-ORBEndpoint iiop://:2020/foobar=12345`
- `-ORBEndpoint iiop://1.1@`
- `-ORBEndpoint iiop://1.1@:1234`
- `-ORBEndpoint iiop://1.1@,1.0@:1234,1.1@`
- `-ORBEndpoint iiop://1.1@foo:2020/portspan=30`

## SHMIOP Endpoints

TAO's SHMIOP pluggable protocol utilizes shared memory as its underlying transport mechanism.

### SHMIOP Endpoint Overview

SHMIOP endpoints in TAO have the similar form to IIOP endpoints:

> `-ORBEndpoint shmiop://V.v@port1,...,W.w@port2`

Where "`V.v`" and "`W.w`" are the SHMIOP protocol versions associated with the given address (port). Currently supported versions are `1.0`, `1.1`, and `1.2`.

### SHMIOP Address Format

SHMIOP addresses are comprised of a port number that the server should listen on.

Port numbers range from `0` (causes port to be chosen by operating system) to `65335`. Port numbers less than `1024` on UNIX systems are considered privileged, and require super-user privileges to access them. Also be aware that some ports may already be in use by other applications.

To have TAO automatically choose an address for a given SHMIOP endpoint, simply omit the address from the endpoint specification as follows:

> `-ORBEndpoint shmiop://`

In this case, an SHMIOP endpoint will be set up on a port chosen by TAO.

### SHMIOP Endpoint Examples

Here are some additional examples of SHMIOP endoints:

- `-ORBEndpoint shmiop://1.0@0`
- `-ORBEndpoint shmiop://1.0@0,3456`
- `-ORBEndpoint shmiop://1.0@0,3456/foobar=300`
- `-ORBEndpoint shmiop:///foobar=2` (notice three slashes "`///`")
- `-ORBEndpoint shmiop://2020/foobar=12345`
- `-ORBEndpoint shmiop://1.1@`
- `-ORBEndpoint shmiop://1.1@1234`
- `-ORBEndpoint shmiop://1.1@,1.0@1234,1.1@`

You must specify the hostname, however, when using SHMIOP with Interoperable Naming Service as you would with IIOP. This is because SHMIOP uses the hostname to determine the validity of an endpoint. That is, it will not try to connect to a remote SHMIOP endpoint locally. For examples:

> `-ORBInitRef MyService=shmiop://1.1@hostname:port/service_name`

## UIOP Endpoints

TAO's UIOP pluggable protocol utilizes local IPC (aka UNIX domain sockets) as its underlying transport mechanism.

### UIOP Endpoint Overview

UIOP endpoints in TAO have the form:

> `-ORBEndpoint uiop://V.v@rendezvous_point1,...,W.w@rendezvous_point2`

Where "`V.v`" and "`W.w`" are the UIOP protocol versions associated with the given rendezvous point. Currently supported versions are `1.0` and `1.1`.

Options are separated from the addresses by a vertical bar '`|`'. For instance, if an IIOP endpoint should have a property foobar of 50 associated with it, then the following endpoint specification could be used

> `-ORBEndpoint 'uiop://1.0@/tmp/my_rendezvous_point|foobar=50'`

Notice that the endpoint is quoted to prevent the shell from interpreting the vertical bar '`|`' as the shell "pipe" character.

### UIOP Address Format

UIOP addresses are comprised of a rendezvous point the server should listen on. The rendezvous point is generally the full path to the desired UNIX domain socket filename. Relative paths can be used, their use is discourages. The maximum length of the rendezvous point is 108 characters, as dictated by the POSIX.1g specification for local IPC rendezvous points. TAO will truncate any rendezvous point name longer than 108 characters.

An UIOP endpoint with a rendezvous point with an absolute path could be:

> `-ORBEndpoint uiop:///tmp/foobar`

In this example, the optional protocol version and endpoint-specific options have been omitted. The rendezvous point `/tmp/foobar` will be created, in this case.

An UIOP endpoint with a rendezvous point with a relative path could be:

> `-ORBEndpoint uiop://foobar` (DISCOURAGED)

Again, rendezvous points with relative paths are discouraged since it is possible that other rendezvous points with the same basename exist on a given system, giving rise to potential ambiguities.

To make TAO choose a rendezvous point automatically, simply omit the rendezvous point from the endpoint specification as follows:

> `-ORBEndpoint uiop://`

This will cause an endpoint to be setup in system temporary directory. Rendezvous points chosen by TAO are prepended with "`TAO`." TAO will always choose rendezvous points with absolute paths.

### UIOP Endpoint Examples

Here are some additional examples of UIOP endoints:

- `-ORBEndpoint uiop://1.0@/tmp/foo1`
- `-ORBEndpoint uiop://1.0@/tmp/foo,1.1@/home/bar/baz`
- `-ORBEndpoint 'uiop://1.1@/tmp/bar|foobar=300'`
- `-ORBEndpoint 'uiop://|foobar=2'`
- `-ORBEndpoint uiop://1.1@`
- `-ORBEndpoint uiop://1.1@,1.0@/tmp/foo,1.1@`

## DIOP Endpoints

TAO's DIOP pluggable protocol utilizes UDP sockets instead TCP sockets (IIOP) as its underlying transport mechanism. This protocol supports unreliable datagram communication, which has certain limitations.

### DIOP Endpoint Overview

Since DIOP endpoints in TAO have the same form as IIOP endpoints, a detailed description is therefore omitted. DIOP has no support for endpoint-specific options.

We recommend explicitly setting port numbers for endpoints since TAO does not support automatic selection of free endpoints for UDP sockets. Instead, the ORB will try to use the same default port number in every case.

### DIOP Endpoint Examples

Here are some additional examples of DIOP endoints:

- `-ORBEndpoint diop://1.0@foo1:2345`
- `-ORBEndpoint diop://1.1@:1234`

## SSLIOP Endpoints

TAO's SSLIOP pluggable protocol facilitates CORBA request invocation over TLS (formerly known as SSL), and is a drop-in replacement for the IIOP pluggable protocol.

The SSLIOP pluggable protocol will actually create two endpoints: one which is meant to accept plain IIOP requests, and another meant to accept SSLIOP requests. As security measure, IIOP requests will be rejected by default unless the server is configured to accept them (See the SSLIOP documentation for additional details).

### SSLIOP Endpoint Format

SSLIOP endpoints basically have the same format as IIOP endpoints. The only difference between the two is that SSLIOP endpoints accept an additional option that allows one to select the port which will accept TLS requests. To make a server open a SSLIOP endpoint on a specific port use the `ssl_port` endpoint option:

- `-ORBEndpoint iiop://foo:1234/ssl_port=1235`

In this case, an IIOP endpoint would be opened on port `1234` and a SSLIOP endpoint on port `1235`. If no `ssl_port` option is supplied, a port will automatically be chosen in the same way a port is automatically chosen for an IIOP endpoint.

Note that the protocol label in the above example is `iiop`, not `ssliop`. Regardless, a SSLIOP endpoint will be opened if the SSLIOP pluggable protocol was loaded. Furthermore, the `ssl_port` endpoint option is only valid if the SSLIOP pluggable protocol is used.

Last modified: Fri Jun 11 16:51:59 PDT 2004