ATTACH(5)                                               ATTACH(5)

          attach, session, nop - messages to initiate activity

          Tnop      tag[2]
          Rnop      tag[2]

          Tsession  tag[2] chal[8]
          Rsession  tag[2] chal[8] authid[28] authdom[48]

          Tattach   tag[2] fid[2] uid[28] aname[28] ticket[72]
          Rattach   tag[2] fid[2] qid[8] rauth[13]

          The nop request does nothing overt but may be used to syn-
          chronize the channel between two service hosts initially.

          The session request is used to initialize a connection
          between a client and a server.  All outstanding I/O on the
          connection is aborted.  The set of messages between session
          requests is called a session. The host's user name (authid)
          and its authentication domain (authdom) identify the key to
          be used when authenticating to this host.  The exchanged
          challenges (chal) are used in the authentication algorithm.
          If authid is a null string no authentication is performed in
          this session.

          The tag should be NOTAG (value 0xFFFF) for a nop or session

          The attach message serves as a fresh introduction from a
          user on the client machine to a server.  The message identi-
          fies the user (uid) and may select the file tree to access
          (aname).  The ticket and auth arguments contains authoriza-
          tion data derived from the exchanged challenges of the
          session message; see auth(6).

          As a result of the attach transaction, the client will have
          a connection to the root directory of the desired file tree,
          represented by fid. An error is returned if fid is already
          in use.  The server's idea of the root of the file tree is
          represented by the returned qid.

          An attach transaction will be generated for kernel devices
          (see intro(3)) when a system call evaluates a file name
          beginning with `#'.  Pipe(2) generates an attach on the ker-
          nel device pipe(3). The mount system call (see bind(2)) gen-
          erates an attach messages to the remote file server.  When

     ATTACH(5)                                               ATTACH(5)

          the kernel boots, an attach is made to the root device,
          root(3), and then an attach is made to the requested file
          server machine.