OXPORT(4)                                               OXPORT(4)

     NAME
          oxport - export name space on a connection using Op

     SYNOPSIS
          o/oxport [ -Ad ] [ -L ms ] [ -x addr ] dir

     DESCRIPTION
          Oxport serves a name space rooted at dir over a connection
          to an Op client. The connection is indeed standard input,
          because the program is implemented to be used with
          listen(1). Using oxport is more efficient in terms of
          latency than using export(4) for RTTs of 1ms or more.

          The program does not fork the current name space, any change
          to the current name space will be visible to clients. This
          is appropriate for exporting the PC name space to terminals,
          while still seeing any change made to the exported namespace
          (eg., new terminal arrivals) but it means that care has to
          be taken to avoid deadlocks (caused whenever the exported
          namespace is mounted in the namespace used by the program).

          The connection is assumed to be trusted and authenticated,
          on the name of the first user attaching to the exported file
          tree.

          Flag -x can be used to make oxport dial addr and serve dir
          over the connection, after reporting the local system name
          to the other end. See ofs(4) for the details. This is used
          in the octopus to export portions of terminals to the cen-
          tral PC.  In this case, the program authenticates and
          encrypts the connection, unless -A is given as an option.

          Note that in the usual case of running oxport from listen it
          will not authenticate or encrypt the channel. That is
          assumed to be done by listen and not by this program.

          Flag -L is used to debug the protocol by pretending that the
          RTT for a RPC is at least ms milliseconds for a message. The
          implementation is a call to sleep(2) before attending each
          client request. Client requests are served concurrently,
          thus this should not affect throughput.

          See intro(O) for a description of the protocol spoken. This
          is important if this program is being used to export
          devices.

     EXAMPLE
          Export (using Op) the entire file tree seen in the current
          name space to clients connecting to tcp!127.0.0.1!4242
          (without authentication nor encryption of the communication

     OXPORT(4)                                               OXPORT(4)

          channel, but with debugging messages enabled):

               listen -At tcp!127.0.0.1!4242 oxport -d / >[2]/dev/cons

          Export our home directory to clients that authenticate,
          encrypting the communication channel:

               listen -a rc4 -t tcp!127.0.0.1!10000 {o/oxport
               /usr/nemo}

          Export the directory /term to the Op client listening at the
          given address:

               o/oxport -x tcp!alboran!16699 /term

     SOURCE
          /usr/octopus/port/oxport.b

     SEE ALSO
          intro(O) and ofs(4).

     BUGS
          Currently, oxport denies access for subtrees of the direc-
          tory exported other than / (that is, it prevents the use of
          the field path in attach(O) requests).