ATTACH(5)							File Formats Manual							 ATTACH(5)

NAME

       attach, session, nop - messages to initiate activity

SYNOPSIS

       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] auth[13]
       Rattach	 tag[2] fid[2] qid[8] rauth[13]

DESCRIPTION

       The nop request does nothing overt but may be used to synchronize 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 message.

       The attach message serves as a fresh introduction from a user on the client machine to a server.  The message identifies the user (uid) and
       may  select  the  file  tree to access (aname).	The ticket and auth arguments contains authorization data derived from the exchanged chal-
       lenges 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.

ENTRY POINTS

       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 kernel device pipe(3).  The mount system call (see bind(2)) generates an attach  messages  to  the  remote  file
       server.	 When  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.

SEE ALSO

       auth(6)

																	 ATTACH(5)