sockets.tex

项目描述: slsnif is a serial port logging utility. It listens to the specified serial port and logs all

\documentstyle[12pt]{article}

\title{The Simple Sockets Library \\ \normalsize\em Version 2.09}
\author{Charles E. Campbell, Jr., {\normalsize Ph.D.} \and Terry McRoberts}

\def\SSL{{\tt SSL}}
\def\IRL{{\small IRL}}
\def\TCP{{\small TCP/IP }}
\def\TradeMark{{\tiny (tm) }}

\newtheorem{example}{Example}[section]

\newcommand{\widepage}{
 \setlength{\footheight}{0.25in}
 \setlength{\topmargin}{0.0in}
 \setlength{\oddsidemargin}{0in}
 \setlength{\textwidth}{6.5in}
 \setlength{\textheight}{8.75in}
 }
\widepage
\renewcommand{\thepage}{}


\begin{document}

\maketitle

\begin{abstract}
{
The {\em Simple Sockets Library} (\SSL) allows~C~programmers to use
interprocess communications via Berkeley sockets simply and quickly.
The programmer is able to move information easily between processes
on the same or different machines connected via Ethernet \TradeMark and using
the \TCP\ protocol.  Most of the \SSL's functions resemble C's file i/o
functions, so~C~programmers will find the \SSL\ easy to learn.
\vspace{1ex}

The \SSL\ currently runs under various {\small UNIX \TradeMark} machines:
{\small IRIX \TradeMark} (Silicon Graphics), SunOS \TradeMark (Sun), Domain O/S
\TradeMark (Apollo), Ultrix \TradeMark (Dec), {\small AIX \TradeMark} ({\small
IBM}), {\small SCO \TradeMark}, {\small OSF \TradeMark}, and {\small VMS} 5.x
\TradeMark, and {\small MS-DOS \TradeMark} (using Borland C++ 5.0).
}

\vspace{.25in}
\begin{table}[h]
  \begin{center}
  \small
  {\bf Keywords} \\
  \footnotesize
  \begin{tabular}{ll}
    Socket Interprocess Communications  & Intermachine Communications \\
    Berkeley Sockets                    & Ethernet                    \\
    \TCP                                & Robotics                    \\
    Machine Control                     &                             \\
  \end{tabular}
  \end{center}
\end{table}

\end{abstract}

\titlepage
\tableofcontents
\newpage
\setcounter{page}{1}
\renewcommand{\thepage}{\arabic{page}}

\section{Introduction}

The {\em Simple Sockets Library} (henceforth to be abbreviated as the \SSL)
allows~C~programmers to develop systems of cooperating programs using Berkeley
streaming Sockets running under the \TCP protocol over Ethernet.  The
\SSL\ provides simple ways to move information between programs running on the
same or different machines and does so with little overhead.  During
experiments with the {\em Sreadbytes} and {\em Swrite} functions, for example,
between two machines,~a~$44,000$ bytes/second transfer rate was achieved with
4~bytes per packet and over $1,000,000$ bytes/second was achieved with
128~bytes per packet.  Of course, heavily loaded networks will affect the rate
individual users achieve.  The \SSL\ provides {\em two-way} communications.

The \SSL\ was designed to resemble the {\small FILE} i/o system provided
by the standard~C~libraries (ie.~fopen, fclose, fputs, etc. map to
\SSL\ analogs Sopen, Sclose, Sputs, etc.).  Thus,~C~programmers typically
find the \SSL\ easy to learn.

A~good analogy for the \SSL\ refers to the phone system.  There are three types
of Sockets supported by the \SSL\ that concern the user:~a~{\em server},~a~{\em
client}, and an {\em accept} socket. ~A~server is analogous to someone waiting
by several phones for~a~call,~a~client is analogous to someone making~a~call,
and an accept is analogous to~a~(server) person accepting the call by picking
up one of the phones.

Thus, one must have~a~server for~a~client to make~a~successful connection.  The
server must in turn accept the connection.  Unlike our overworked server
person, however, the computer using the \SSL\ is perfectly happy handling
multiple ``accept'' Sockets concurrently.

The \SSL\ itself is provided in three main parts (see Table~\ref{three-parts}).
The {\em Library} is composed of~C~functions and the {\em PortMaster} and the
{\em Utilities} are self-contained programs.

\begin{table}[ht]
  \caption{\bf The Three Parts of the \SSL}
  \label{three-parts}
  \begin{description}

  \item[Library] The functions that the users will link to are in the
    library.

  \item[PortMaster] The PortMaster is~a~d\"aemon program which runs in
    the background.  It allows {\em clients} to connect to {\em servers}
    using any available ports.

  \item[Utilities] There are several utility programs provided with
    the \SSL: {\tt sktdbg}, {\tt srmsrvr}, and {\tt spmtable}.
  \end{description}
\end{table}

The \SSL\ has been in use at {\small NASA}'s Goddard Space Flight Center's
Intelligent Robotics Laboratory (\IRL) since May, 1991.  The software appears
to be stable at the current writing and reasonably robust.  For example, the
PortMaster,~a~background process provided in the \SSL\ distribution, is
resistant to hanging (and thereby being unresponsive). It uses {\em
Stimeoutwait\/}s (see the Reference Manual) to return to its normal quiescent
mode when communications with one of its clients ceases unexpectedly.

The \IRL\ uses the \SSL\ to control its three robots; its use of the Ethernet
is consequently somewhat heavy.  Those of you who wish to control machinery or
otherwise present~a~heavy load may wish to purchase~a~``bridge'' to isolate
your machines from your local network.  This isolation will benefit both the
you and the network, as the heavy user will not be afflicted with slowdowns due
to the network and the network will not be bothered with lots of packets which
slows all its users down.

Please contact {\small COSMIC} if you have serious difficulties (ie.~bugs)
with the \SSL.


\newpage
\section{The Library}

The user of the \SSL\ accesses it by linking his or her program to~a~{\em
library}. ~A~software library is typically~a~single file which consists of some
linkage information along with pre-compiled {\em object code}; unfortunately,
methods for producing~a~library and linking to it vary from system to system
and compiler to compiler.  Directions for several systems appear in the Section
on Implementation.

Practically speaking,~a~library is composed of~a~number of pre-compiled C
functions to be utilized by the programmer.  The calls made available in the
\SSL\ are reminiscent of those used by the various file functions in the C
language (see Table~\ref{reminiscent}).

\begin{table}[thb]
  \begin{center}
  \caption{Simple Sockets and Related File {\protect\small I/O} Functions}
  \label{reminiscent}
  \begin{tabular}{||l|l||}                        \hline\hline
  {\em File Function} & {\em Socket Function}     \\ \hline
  fopen               & Sopen                     \\
  fclose              & Sclose                    \\
  fread               & Sread                     \\
  fwrite              & Swrite                    \\
  fgets               & Sgets                     \\
  fputs               & Sputs                     \\
  fprintf             & Sprintf                   \\
  fscanf              & Sscanf                    \\ \hline\hline
  \end{tabular}
  \end{center}
\end{table}

The Sockets library depends upon the {\em PortMaster} running on your host
machine. Only one copy of the PortMaster need be running at any time on~a~given
machine, and may be started up by anyone by running the {\em Spm} program in
the background.  On Unix, the {\em Spm} program will put itself into the
background.  One may determine if your system has~a~PortMaster running by
typing {\em spmtable} first -- it will inform you of any existing servers if
the PortMaster is up or tell you that the PortMaster is not up otherwise.

A~new feature of the \SSL\ allows servers to share another machine's PortMaster.
Thus, the \SSL\ supports both distributed and centralized socket name to port
mapping.  If the machine on which~a~server is to run doesn't have~a~PortMaster,
such as older {\small MSDOS} machines, then it can ``borrow'' another machine's
PortMaster.

A~program may open~a~server Socket,~a~client Socket, or an accept Socket.
Following the phone system analogy, assume that~a~server Socket is opened
first.  Then,~a~different program may open~a~client Socket which attempts to
connect to the server -- it succeeds when the server program ``notices'' that
there is~a~connection waiting on the server Socket and then generates an accept
Socket.  The client Socket can open, however, before the server accepts the
client; there just won't be any two-way communication until the server does
accept the client.

\subsection{User Guide}

Software using~C~must \verb`#include "sockets.h"` and must link to the \SSL.
Directions for doing so will vary from system to system and also depend upon
where the installer placed the libraries.  Please refer to your compiler
documentation and the \SSL\ installer to know how to set up library linkage
paths and for the include path to the {\em sockets.h} file.

The software below illustrates some typical Socket code fragments to get a
connected socket, assuming that the \verb`sockets.h` file is on your compiler's
include search path.  If the \verb`sockets.h` file has been placed in a
standard system directory (not wise - updates to the compiler may wipe it off!)
then you may have to substitute \verb`#include <sockets.h>` for \verb`#include
"sockets.h"` in the following examples.

\begin{example}~A~server with one accept     \\ \label{one-accept}
\verb`    #include "sockets.h"`              \\
\verb`    Socket *server;`                   \\
\verb`    Socket *skt;`                      \\
\verb`    server= Sopen("servername","s");`  \\
\verb`    skt   = Saccept(server);`          \\
\verb`    ...`                               \\
\verb`    Sclose(skt);`                      \\
\verb`    Sclose(server);`
\end{example}

Note in Example~\ref{one-accept} that the servername is completely up to the
programmer to select.  Please note that all servers share the same namespace on
any given machine, however.

\begin{example}~A~server with multiple accepts \\ \label{multi-accept}
\verb`    #include "sockets.h"`             \\
\verb`    Socket *server=NULL;`             \\
\verb`    Socket *skt=NULL;`                \\
\verb`    server= Sopen("servername","s");` \\
\verb`    do {`                             \\
\verb`        skt   = Saccept(server);`     \\
\verb`        ...`                          \\
\verb`        Sclose(skt);`                 \\
\verb`        } while(whatever);`           \\
\verb`    Sclose(server);`
\end{example}

Again, the programmer may select any servername.  Note that the {\em accept}
Socket (``skt'') is re-used in Example~\ref{multi-accept}.

\begin{example}~A~client                    \\ \label{client}
\verb`    #include "sockets.h"`             \\
\verb`    Socket *client;`                  \\
\verb`    client= Sopen("serverName","c");` \\
\verb`    ...`                              \\
\verb`    Sclose(client);`
\end{example}

In Example~\ref{client}, the \verb`serverName` may be in the optional form
\verb`serverName@machineName`.  Without the machine name specification, the
PortMaster on the machine that the client is running on will be searched for
the server.  The \verb`smsrvr.c` and \verb`smclient.c` example programs provided
in the \SSL\ distribution give complete illustrations of Examples~\ref{one-accept}
and \ref{client}.

\begin{example} Using Sopenv                                 \\ \label{using-sopenv}
\verb`    #include "sockets.h"`                              \\
\verb`    Socket *client;`                                   \\
\verb`    while(1) {`                                        \\
\verb`        client= Sopenv("serverName","c","SKTPATH");`   \\
\verb`        if(client) break;`                             \\