flush(5) [plan9 man page]

FLUSH(5)							File Formats Manual							  FLUSH(5)

NAME

       flush - abort a message

SYNOPSIS

       Tflush  tag[2] oldtag[2]
       Rflush  tag[2]

DESCRIPTION

       When  the  response to a request is no longer needed, such as when a user interrupts a process doing a read(2), a Tflush request is sent to
       the server to purge the pending response.  The message being flushed is identified by oldtag.  The semantics of flush depends  on  messages
       arriving in order.

       The  server  must  answer  the flush message immediately.  If it recognizes oldtag as the tag of a pending transaction, it should abort any
       pending response and discard that tag.  In either case, it should respond with an Rflush echoing the tag (not oldtag) of  the  Tflush  mes-
       sage.  A Tflush can never be responded to by an Rerror message.

       When  the client sends the Tflush, it should disregard all messages received with tag oldtag until the corresponding Rflush is received, at
       which point oldtag may be recycled for subsequent messages.

       Several exceptional conditions are handled correctly by the above specification: sending multiple flushes for  a  single  tag,  flushing  a
       Tflush, and flushing an invalid tag.

																	  FLUSH(5)

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)