ATTACH(5) File Formats Manual ATTACH(5)
attach, session, nop - messages to initiate activity
Tsession tag chal
Rsession tag chal authid authdom
Tattach tag fid uid aname ticket auth
Rattach tag fid qid rauth
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) iden-
tify 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 ses-
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 argu-
ments contains authorization 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 connec-
tion 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 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