MAN.9FRONT.ORG RTFM


     FLUSH(5)                                                 FLUSH(5)

     NAME
          flush - abort a message

     SYNOPSIS
          size[4] Tflush tag[2] oldtag[2]
          size[4] 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 should 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 message.  A Tflush can never
          be responded to by an Rerror message.

          The server may respond to the pending request before
          responding to the Tflush.  It is possible for a client to
          send multiple Tflush messages for a particular pending
          request.  Each subsequent Tflush must contain as oldtag the
          tag of the pending request (not a previous Tflush).  Should
          multiple Tflushes be received for a pending request, they
          must be answered in order.  A Rflush for any of the multiple
          Tflushes implies an answer for all previous ones.  There-
          fore, should a server receive a request and then multiple
          flushes for that request, it need respond only to the last
          flush.

          When the client sends a Tflush, it must wait to receive the
          corresponding Rflush before reusing oldtag for subsequent
          messages.  If a response to the flushed request is received
          before the Rflush, the client must honor the response as if
          it had not been flushed, since the completed request may
          signify a state change in the server.  For instance, Tcreate
          may have created a file and Twalk may have allocated a fid.
          If no response is received before the Rflush, the flushed
          transaction is considered to have been canceled, and should
          be treated as though it had never been sent.

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