2009/4/21 erik quanstrom <quans...@quanstro.net>: > what is the important use case of flush and why is this > so important that it drives the design?
actually the in-order delivery is most important for Rmessages, but it's important for Tmessages too. consider this exchange (C=client, S=server), where the Tflush is sent almost immediately after the Twalk: C->S Twalk tag=5 fid=22 newfid=24 C->S Tflush tag=6 oldtag=5 S->C Rflush tag=6 if outgoing tags 5 and 6 were swapped, we could get this possible exchange: C->S Tflush tag=6 oldtag=5 S->C Rflush tag=6 C->S Twalk tag=5 fid=22 newfid=24 S->C Rwalk tag=5 thus the flush is incorrectly ignored. this won't break the protocol though, but consider this example, where Rmsgs can be delivered out-of-order: here, the server replies to the Twalk message before it receives the Tflush. the clone succeeds: C->S Twalk tag=4 fid=22 newfid=23 C->S Tflush tag=5 oldtag=4 S->C Rwalk tag=4 S->C Rflush tag=5 here the two reply messages are switched (erroneously): C->S Twalk tag=4 fid=22 newfid=23 C->S Tflush tag=5 oldtag=4 S->C Rflush tag=5 S->C Rwalk tag=4 the Rflush signals to the client that the Twalk was successfully flushed, so the client considers that the clone failed, whereas it actually succeeded. the Rwalk is considered a spurious message (it may even interfere destructively with subsequent Tmsg). result: death and destruction. anyway, this is moot - from the original plan 9 paper: "The 9P protocol must run above a reliable transport protocol with delimited messages. [...] UDP [RFC768] does not provide reliable in-order delivery." (is this the canonical reference for this requirement? the man page doesn't seem to say it) the protocol doesn't guarantee that requests are *processed* in order, but that's a different thing entirely, and something my half-baked proposal seeks to get around.
