From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9260943c5ab5bb05fd7db0b5f7cfdbc0@quanstro.net> References: <9260943c5ab5bb05fd7db0b5f7cfdbc0@quanstro.net> Date: Tue, 21 Apr 2009 15:03:17 +0100 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan9 - the next 20 years Topicbox-Message-UUID: ed0997f8-ead4-11e9-9d60-3106f5b1d025 2009/4/21 erik quanstrom : > 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.