.TH FLUSH 5.SH NAMEflush \- abort a message.SH SYNOPSIS.ta \w'\fLTflush 'u.IR size [4].B Tflush.IR tag [2].IR oldtag [2].br.IR size [4].B Rflush.IR tag [2].SH DESCRIPTIONWhen the response to a request is no longer needed, such as whena user interrupts a process doing a.IR read (2),a.B Tflushrequest is sent to the server to purge the pending response.The message being flushed is identified by.IR oldtag .The semantics of.B flushdepends on messages arriving in order..PPThe server should answer the.B flushmessage immediately.If it recognizes.I oldtagas the tag of a pending transaction, it should abort any pending responseand discard that tag.In either case, it should respond with an.B Rflushechoing the.I tag(not.IR oldtag )of the.B Tflushmessage.A.B Tflushcan never be responded to by an.B Rerrormessage..PPThe server may respond to the pending request beforeresponding to the.BR Tflush .It is possible for a client to send multiple.B Tflushmessages for a particular pending request. Eachsubsequent.B Tflushmust contain as.I oldtagthe tag of the pending request (not a previous.BR Tflush ).Should multiple.BR Tflush esbe received for a pending request, they must be answered inorder. A.B Rflushfor any of the multiple.BR Tflush esimplies an answer for all previous ones. Therefore, shoulda server receive a request and then multiple flushes for thatrequest, it need respond only to the last flush..PPWhen the client sends a .BR Tflush ,it must wait to receive the corresponding.B Rflushbefore reusing.I oldtagfor subsequent messages.If a response to the flushed request is received before the.BR Rflush ,the client must honor the responseas if it had not been flushed,since the completed request may signify a state change in the server.For instance,.B Tcreatemay have created a file and.B Twalkmay have allocated a fid.If no response is received before the.BR Rflush ,the flushed transaction is considered to have been canceled,and should be treated as though it had never been sent..PPSeveral exceptional conditions are handled correctly by the above specification:sending multiple flushes for a single tag,flushing after a transaction is completed,flushing a.BR Tflush ,and flushing an invalid tag.
.TH FLUSH 5
.SH NAME
flush \- abort a message
.SH SYNOPSIS
.ta \w'\fLTflush 'u
.IR size [4]
.B Tflush
.IR tag [2]
.IR oldtag [2]
.br
.IR size [4]
.B Rflush
.IR tag [2]
.SH DESCRIPTION
When the response to a request is no longer needed, such as when
a user interrupts a process doing a
.IR read (2),
a
.B Tflush
request is sent to the server to purge the pending response.
The message being flushed is identified by
.IR oldtag .
The semantics of
.B flush
depends on messages arriving in order.
.PP
The server should answer the
.B flush
message immediately.
If it recognizes
.I 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
.B Rflush
echoing the
.I tag
(not
.IR oldtag )
of the
.B Tflush
message.
A
.B Tflush
can never be responded to by an
.B Rerror
message.
.PP
The server may respond to the pending request before
responding to the
.BR Tflush .
It is possible for a client to send multiple
.B Tflush
messages for a particular pending request. Each
subsequent
.B Tflush
must contain as
.I oldtag
the tag of the pending request (not a previous
.BR Tflush ).
Should multiple
.BR Tflush es
be received for a pending request, they must be answered in
order. A
.B Rflush
for any of the multiple
.BR Tflush es
implies an answer for all previous ones. Therefore, should
a server receive a request and then multiple flushes for that
request, it need respond only to the last flush.
.PP
When the client sends a
.BR Tflush ,
it must wait to receive the corresponding
.B Rflush
before reusing
.I oldtag
for subsequent messages.
If a response to the flushed request is received before the
.BR 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,
.B Tcreate
may have created a file and
.B Twalk
may have allocated a fid.
If no response is received before the
.BR Rflush ,
the flushed transaction is considered to have been canceled,
and should be treated as though it had never been sent.
.PP
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
.BR Tflush ,
and flushing an invalid tag.