Museum

Home

Lab Overview

Retrotechnology Articles

⇒ Online Manual

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

incd(8)

xpe(7)

et(7)

xr(7)

xs(7)

clone(7)



  xpe(7)                              CLIX                              xpe(7)



  NAME

    xpe - STREAMS XNS PEP driver

  DESCRIPTION

    The xpe device is a STREAMS driver that provides the services of the
    Packet Exchange Protocol (PEP) to applications and other protocols on the
    host machine.  PEP is the transaction-based connectionless transport layer
    protocol of the Xerox Network System (XNS) protocol suite.

    The clone opens may be performed on the xpe device to find the first
    available free minor device.

    The xpe device communicates on its upper streams using the AT&T Transport
    Provider Interface (TPI) providing support for the AT&T Transport Layer
    Interface (TLI) to applications.  The xpe device provides the T_CLTS
    connectionless protocol service (as specified by TPI/TLI) to its upstream
    clients.

    The PEP protocol defines a protocol that exchanges packets between a
    client socket and a server socket.  The client side generates PEP requests
    and sends them to the server.  The server side receives client requests
    from the network, does some processing, and returns PEP responses to the
    clients.  TLI makes no such client/server distinction for its
    connectionless devices.  To provide for the distinction, xpe may be put
    into client or server mode when the bind request is made, as described
    below.

    In client mode, unitdata requests will be sent downstream to xpe and a
    corresponding PEP request will be sent.  The xpe device will then wait for
    the PEP response to return from the server, possibly retransmitting the
    PEP request if no response is seen for the specified retransmit timeout.
    If a matching PEP response (or responses) arrives, a unitdata indication
    will be sent upstream by xpe.  If no matching PEP response arrives within
    the specified timeout, a unitdata error indication is sent upstream by
    xpe.  In client mode, PEP requests sent to the socket bound by the client
    will be silently ignored.

    In server mode, xpe waits for incoming PEP requests sent to the local
    socket and sends corresponding unitdata indications upstream.  To respond
    to the PEP request, the server sends unitdata requests downstream to xpe.

    The address format used in the bind, unitdata request, and unitdata
    indication operations is an array of 12 bytes.  The network number is
    contained in the first four bytes of the array, the host address is
    contained in the next six bytes of the array, and the socket number is
    contained in the last two bytes of the array.  Each of the three numbers
    (network, host, and socket) is filled in with network order (most
    significant byte first.)




  2/94 - Intergraph Corporation                                              1






  xpe(7)                              CLIX                              xpe(7)



    For example, to fill in an address structure with the network address
    0x000134ab, host address 08-00-36-ab-cd-03, and socket number 0x0045 the
    following C code is used:

    char addr[12];
    addr[0] = 0x00;
    addr[1] = 0x01;
    addr[2] = 0x34;
    addr[3] = 0xAB;
    addr[4] = 0x08;
    addr[5] = 0x00;
    addr[6] = 0x36;
    addr[7] = 0xAB;
    addr[8] = 0xCD;
    addr[9] = 0x03;
    addr[10] = 0x00;
    addr[11] = 0x45;

    Only the socket part of the address is meaningful in bind requests,
    telling xpe which socket to bind.  On return from a successful bind, the
    entire bound address will be placed in the ret address parameter buffer.
    The socket number returned may be different than the one requested if that
    socket is already in use elsewhere in the system.

    When binding, the qlen value of the req structure determines whether the
    stream will be used for PEP client or PEP server processing.  A qlen of
    zero indicates a client; nonzero indicates a server.

    The xpe device supports TLI options associated with unitdata requests and
    unitdata indications.  The options format is the following xpeopts_s
    structure defined in <sys/xns/xns.h>:

    typedef unsigned char u8;
    typedef struct xpeopts_s {
         u8   xpeo_client_type[2];
         char xpeo_retries;
         char xpeo_seconds_per_retry;
         u8   xpeo_id[4];
         u8   xpeo_pass_xropts;
         u8   xpeo_wants_multiple_replies;
    } XPE_OPTS;

    The xpeo_client_type field contains the PEP client type to be sent by
    unitdata requests or that was received in unitdata indications.

    The xpeo_retries field is always 0 in unitdata indications.  It indicates
    the number of retransmissions that should be attempted from client xpe
    streams.  Packets sent from xpe server streams are not retransmitted.  For
    clients, if this value is set to zero in a unitdata request, the default
    retry count of 10 is used.




  2                                              Intergraph Corporation - 2/94






  xpe(7)                              CLIX                              xpe(7)



    The xpeo_seconds_per_retry field is always 0 in unitdata indications.  For
    client unitdata requests (PEP requests) this value indicates the number of
    seconds between retries.  If this value is set to 0, the first retry will
    occur after two seconds.  Subsequent retries will be based on a round-trip
    time estimate obtained from the downstream xr module for the specified
    destination address.

    The xpeo_id field contains the PEP ID of the received packet in unitdata
    indications.  For xpe server streams, this field indicates the value to
    use for the PEP ID of the response being sent (allowing servers to match
    response PEP IDs to the client's request PEP IDs).  For xpe client
    streams, this field is ignored, and xpe generates a unique ID for each
    client packet.

    The xpeo_pass_xropts field is always 0 in unitdata indications.  In
    unitdata requests, if this field is nonzero, an xr_opts structure should
    immediately follow the xpe_opts structure in the unitdata request options
    buffer.  This option is used only to support expanding rings.

    The xpeo_wants_multiple_replies field is always 0 in unitdata indications.
    For xpe client streams, nonzero xpeo_wants_multiple_replies values
    indicate that all replies (not just the first one) to a client broadcast
    (or multicast) request should be received and passed upstream in unitdata
    indications.

  FILES

    /dev/xpe
           Special device file for xpe.

    /usr/include/sys/xns/xns.h
           XNS header file.

    /usr/include/sys/xns/common.h
           XNS common definitions header file.

    /usr/include/sys/xns/mi.h
           XNS miscellaneous header file.

    /usr/include/sys/lihdr.h
           Logical Link Interface header file.

  NOTES

    On CLIX systems, incd is usually responsible for creating the network
    configuration of streams drivers/modules/multiplexors, including xpe.
    Manual configuration is necessary only in rare circumstances.

  RELATED INFORMATION

    Commands: incd(8)



  2/94 - Intergraph Corporation                                              3






  xpe(7)                              CLIX                              xpe(7)



    Files: et(7), xr(7), xs(7), clone(7)





















































  4                                              Intergraph Corporation - 2/94




Typewritten Software • bear@typewritten.org • Edmonds, WA 98026