⟦39c8d8785⟧

TextFile

% run this through LaTeX with the appropriate wrapper

\f

\chapter	{Defining New Services}\label{services}
There are several components which are manipulated when a service is invoked.
Briefly,
let us consider how to define a new service.
There are three databases to be managed:
\begin{describe}
\item[isoentities:] which maintains the mappings between application-entity
	information and presentation addresses
	(described in Chapter~\ref{isoentities});

\item[isobjects:] which maintains the mappings between object descriptors and
	object identifiers
	(described in Chapter~\ref{isobjects});
	and,

\item[isoservices:] which maintains the mappings between textual descriptions
	of services, service selectors, and local programs
	(described in Chapter~\ref{isoservices} of \voltwo/).
\end{describe}

For the remainder of this chapter,
consider any fictitious service
with suffix \verb"servicestore"
(e.g., for the host \verb"gremlin",
the service might be known as \verb"gremlin-servicestore"),
and with an application context name of \verb*"local service".

There are many ways in which the mappings can be performed.
Two approaches are described in this chapter.
If you wish to use a different variation,
then presumably you know enough about what you are doing not to need
additional documentation here!

\f

\section	{Standard Services}\label{service:standard}
The ``standard'' approach is  the simplest and most straight-forward mapping
strategy.

First,
the abstract syntax {\em presentation context information\/} (PCI) of
the service,
along with the {\em application context\/} of the service should be defined.
These are object identifiers (as described in Section~\ref{psap:oid} on
page~\pageref{psap:oid}).
The object identifier tree \verb"1.17.2" has been usurped for
defining local services using {\em The ISO Development Environment}.
Choose \verb"n",
where \verb"n" is the lowest unassigned number in the \verb"1.17.2.n" subtree,
for use by the service
(\verb"n" should be an integer greater than \verb"0").
Now edit the \man isobjects(5) file thusly:
\begin{quote}\small\begin{verbatim}
"local service pci"    1.17.2.n.1
"local service"        1.17.2.n.2
\end{verbatim}\end{quote}

Next,
the template for the {\em application-entity information\/} and
{\em presentation address\/} of the service should be defined.
These are used for outgoing connections.
The application-entity information portion is currently an object identifier,
from the \verb"1.17.4.1" subtree.
The presentation address portion is a presentation selector,
a session selector, a transport selector, and a set of network addresses.
Currently, the convention is to use empty presentation and session selectors,
a unique transport selector,
and a simple default template for the network addresses
(the templates will be filled-in during connection establishment).
The choice of a transport selector is troublesome;
for the present,
a 16--bit binary selector space is suggested.
Choose \verb"p",
where \verb"p" is the lowest unassigned TSAP ID between \verb"1024" and
\verb"2047" inclusive.
Now edit the \man isoentities(5) file thusly:
\begin{quote}\small\begin{verbatim}
default servicestore    1.17.4.1.n  ""  ""  #p/
\end{verbatim}\end{quote}

Finally,
the program on the local system implementing the service should be defined.
This is used for incoming connections.
Given the strategy used for allocating presentation addresses above,
one need only map between a transport selector and a program.
Edit the \man isoservices(5) thusly:
\begin{quote}\small\begin{verbatim}
"tsap/servicestore"    #p  program arg1 arg2 ... argN
\end{verbatim}\end{quote}

\f

\section	{GOSIP Services}\label{service:gosip}
The U.S.~Government OSI Profile\cite{GOSIP} specifies a somewhat different
mapping strategy.
Rather than list the differences,
the entire process is described here.

First,
the abstract syntax {\em presentation context information\/} (PCI) of the
service,
along with the {\em application context\/} of the service should be defined.
These are object identifiers (as described in Section~\ref{psap:oid} on
page~\pageref{psap:oid}).
As previously described,
the object identifier tree \verb"1.17.2" is used to define local services.
Choose \verb"n",
where \verb"n" is the lowest unassigned number in the \verb"1.17.2.n" subtree,
for use by the service
(\verb"n" should be an integer greater than \verb"0").
Now edit the \man isobjects(5) file thusly:
\begin{quote}\small\begin{verbatim}
"local service pci"    1.17.2.n.1
"local service"        1.17.2.n.2
\end{verbatim}\end{quote}

Next,
the template for the {\em application-entity information\/} and
{\em presentation address\/} of the service should be defined.
These are used for outgoing connections.
The application-entity information portion is currently an object identifier,
from the \verb"1.17.4.1" subtree.
The presentation address portion is a presentation selector,
a session selector, a transport selector, and a set of network addresses.
Currently, the convention is to use a unique presentation selector,
along with standard values for the session and transport selectors,
and a simple default template for the network addresses
(the templates will be filled-in during connection establishment).
The choice of the selectors is mandated by GOSIP:
a 16--bit binary selector space is used.
Choose \verb"p",
where \verb"p" is the lowest unassigned PSAP ID between \verb"1024" and
\verb"2047" inclusive.
Now edit the \man isoentities(5) file thusly:
\begin{quote}\small\begin{verbatim}
default servicestore    1.17.4.1.n    #p/#1/#1/
\end{verbatim}\end{quote}

Finally,
the program on the local system implementing the service should be defined.
This is used for incoming connections.
Given the strategy used for allocating presentation addresses above,
one need only map between a presentation selector and a program.
Edit the \man isoservices(5) thusly:
\begin{quote}\small\begin{verbatim}
"psap/servicestore"    #p  program arg1 arg2 ... argN
\end{verbatim}\end{quote}

This strategy is less efficient than the first approach as it requires the
\man tsapd(8c) daemon to parse more information from the remote peer prior to
invoking the program which implements desired application context.

\f

\section	{Static Servers}\label{static:services}
In Section~\ref{acs:server},
two different server disciplines,
the dynamic and the static approaches,
were described.
Thus far,
this chapter has described the dynamic approach.
The distinguishing mechanism of this discipline is that the entry in the
\man isoentities(5) file specifies \verb"default" for the host portion of the
service, e.g.,
\begin{quote}\small\begin{verbatim}
default servicestore    1.17.4.1.n    #p/#1/#1/
\end{verbatim}\end{quote}

To implement the static server discipline,
as described in Section~\ref{acs:server},
one defines the service for a particular host and specifies the non-standard
network (sub)address that the service exists on.
For example:
\begin{quote}\small\begin{verbatim}
gremlin imagestore    1.17.4.1.n \
                      #p/#1/#1/Internet=gremlin+17000
\end{verbatim}\end{quote}
Indicates that the service \verb"gremlin-imagestore" is available only by
using the TCP network service to the host \verb"gremlin" and then using TCP
port \verb"17000".
Similar definitions may be made for hosts using an X.25 service.
Further,
as is the case with any entry in the \man isoentities(5) file,
multiple network address may be present for a single service.
In these cases,
the server listens on all of these addresses.

After making a suitable definition in the \man isoentities(5) file,
the server program must be started
(either by hand or automatically from some system startup file,
e.g., \file{/etc/rc.local}) without any arguments.
The server program,
using the \verb"isodeserver" routine described on page~\pageref{isodeserver}
will then perform the appropriate actions to start listening on the desired
addresses.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦39c8d8785⟧ TextFile

Derivation

TextFile
