\documentclass[draft,a4paper,11pt,twoside]{article}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage[scaled=0.9]{DejaVuSansMono}
\usepackage[scaled=0.9]{DejaVuSans}
\usepackage[scaled=0.9]{DejaVuSerif}
\linespread{1.05}

\addtolength{\oddsidemargin}{-0.2in}
\addtolength{\evensidemargin}{-0.6in}
\addtolength{\textwidth}{0.5in}

\pagestyle{headings}

\newcommand{\cmdline}[1]{\texttt{#1}}
\newcommand{\code}[1]{\texttt{#1}}

\usepackage[T1]{url}
\newcommand{\email}{\begingroup \urlstyle{sf}\Url}
\newcommand{\file}{\begingroup \urlstyle{tt}\Url}
\newcommand{\envvar}{\begingroup \urlstyle{tt}\Url}



\title{The omniNames CORBA Naming Service}

\date{omniORB 4.2}

\begin{document}

\maketitle

\section{Introduction}

omniNames is omniORB's implementation of the OMG's COS Naming Service
Specification.  It offers a way for a client to turn a human-readable
name into an object reference, on which the client can subsequently
invoke operations in the normal way.  See the OMG specification for
full details of the functionality provided by the Naming Service.

The Naming Service stores a set of bindings of names to objects.
These bindings can be arranged as an arbitrary directed graph,
although they are often arranged in a tree hierarchy.  Each node in
the graph is a \emph{naming context}.  There is a `root' context at
which name lookups usually start.  This is the object returned by the
call to \code{CORBA::ORB::resolve\_initial\_references("NameService")}.


\section{Data file}

omniNames persists its contents in a data file. The data file takes
the form of a `redo log', to which it writes out an entry every time a
change is made to the naming graph.  The directory in which this log
file is written can be specified with the \cmdline{-datadir} command
line option or the \envvar{OMNINAMES_DATADIR} environment variable.
When omniNames is restarted it uses the data file so that it can
regenerate the naming graph.

Periodically the data file is checkpointed, removing unnecessary
entries from the file.  The idle time between checkpoints defaults to
15 minutes. That can be overridden by specifying a period in seconds
in the \envvar{OMNINAMES_ITBC} environment variable.

The name of the data file name normally includes the hostname, in the
form \file{omninames-}\textit{hostname}\file{.dat}. To suppress
inclusion of the hostname, start omniNames with the
\cmdline{-nohostname} option.

Previous versions of omniNames referred to the data file as a `log
file', and the file had the extension `\file{.log}'. When omniNames
starts up, it will accept a data file with the extension `\file{.log}'
and replace it with one with the extension `\file{.dat}'.


\section{Starting omniNames and configuring omniORB}

When starting omniNames for the first time, you can either let it
start with the default TCP port of 2809, or you can specify the port
number on which it should listen.  This is written to the data file so
that on subsequent invocations it will listen on the same port number
and thus can be accessible through the same object reference.  When
omniNames starts up successfully it writes the stringified object
reference for its root context on standard error.

At startup, omniORB reads its configuration from \file{omniORB.cfg} or
from the Windows registry. Amongst other settings, the configuration
contains the object reference to the root context of the Naming
Service.  This object reference is returned by
\code{resolve\_initial\_references("NameService")}. There are a number
of methods of specifying the root naming context---see the omniORB
manual for details.

\section{Command line parameters}

omniNames accepts the following command line parameters.

\vspace{\baselineskip}

\noindent\begin{tabular}{lp{.8\textwidth}}
%HEVEA\\

\cmdline{-help} &
    Output usage information.\\[.5\baselineskip]

\cmdline{-start }\textit{[port]} &
    Start omniNames for the first time, listening on
    \textit{port}.\\[.5\baselineskip]

\cmdline{-always} &
    In conjunction with \cmdline{-start}, always start up
    omniNames, even if its data file already exists.\\[.5\baselineskip]

\cmdline{-datadir }\textit{directory} &
    Specifies the directory for the data file, overriding the
    default.\\[.5\baselineskip]

\cmdline{-logdir }\textit{directory} &
    Equivalent to \cmdline{-datadir}, for compatibility with previous
    omniNames versions.\\[.5\baselineskip]

\cmdline{-errlog }\textit{filename} &
    Causes trace output that would normally be sent to stderr to go to the
    specified file instead.\\[.5\baselineskip]

\cmdline{-nohostname} &
    Normally, omniNames includes the host name in the name of the data
    file. This option disables that, meaning the data file can be used
    on a different host, or if the host name changes.\\[.5\baselineskip]

\cmdline{-install }\textit{[port]} &
    On Windows, install omniNames service. See below.\\[.5\baselineskip]

\cmdline{-manual} &
    On Windows, specify that the service should be configured to
    require manual start. See below.\\[.5\baselineskip]

\cmdline{-remove} &
    On Windows, uninstall omniNames service. See below.\\[.5\baselineskip]

\end{tabular}


\section{Machines with multiple IP addresses}

The CORBA naming service is a tree (or graph) of \code{NamingContext}
CORBA objects. For each of those CORBA objects, the object reference
contains details about the \emph{endpoint}---i.e.\ the host address
and port---that is used to contact the object.

When the machine running omniNames has multiple IP addresses, omniORB
listens for incoming connections on all addresses, but it arbitrarily
picks one of the addresses to publish in object references. It might
pick the `wrong' one, meaning that clients connect to the configured
root context successfully, but then fail to connect to the
sub-contexts. To force omniORB to publish the correct IP address, use
the \cmdline{-ORBendPointPublish} command line parameter:

\begin{quote}
\cmdline{-ORBendPointPublish giop:tcp:}\textit{address}\cmdline{:}
\end{quote}

\noindent where \textit{address} can be an IP address or a host name.

Occasionally, it is necessary to limit omniNames to listen on just one
of a machine's IP addresses. To do that, use \cmdline{-ORBendPoint} to
specify the address to listen on. In this case, you should also
specify a port (e.g.\ the standard 2809), otherwise an arbitrary
ephemeral port will be used for the endpoint:

\begin{quote}
\cmdline{-ORBendPoint giop:tcp:}\textit{address}\cmdline{:2809}
\end{quote}


\section{Windows service}

omniNames can be run as a Windows service. To install the service, run
with the \cmdline{-install} command line option, with a port to
override the default 2809 if necessary. The command line should
include any other parameters of relevance, such as the data directory
and error log file. It is particularly important to specify an error
log file, since the service runs in an environment where stderr goes
nowhere.

The service is normally configured to start at system startup time.
Specifying \cmdline{-manual} configures it for manual startup.
Regardless of that setting, the service is not automatically started
at the time it is installed. It should be started manually with the
service control manager if it is to run before the next system
restart.

Once installed, the service can be uninstalled by running omniNames
with the \cmdline{-remove} option.


\end{document}
