Subject: SSH FTP - 6.1 Request Synchronization and Reordering

From: Tobias Ringstrom <[email-masked]>
Date: Sun, 10 Feb 2002 01:05:25 +0100 (CET)

Hello!

I'm reading the SFTP-draft dated October 2001, and I think that section
6.1 is somewhat easy to misinterpret:

   6.1 Request Synchronization and Reordering

   The protocol and implementations MUST process requests relating to
   the same file in the order in which they are received.  In other
   words, if an application submits multiple requests to the server, the
   results in the responses will be the same as if it had sent the
   requests one at a time and waited for the response in each case.  For
   example, the server may process non-overlapping read/write requests
   to the same file in parallel, but overlapping reads and writes cannot
   be reordered or parallelized.  However, there are no ordering
   restrictions on the server for processing requests from two different
   file transfer connections.  The server may interleave and parallelize
   them at will.

   There are no restrictions on the order in which responses to
   outstanding requests are delivered to the client, except that the
   server must ensure fairness in the sense that processing of no
   request will be indefinitely delayed even if the client is sending
   other requests so that there are multiple outstanding requests all
   the time.

Reading the first paragraph, it is easy to get the impression that
read/write requests to the same file cannot be reordered, not the
responses.  Perhaps it would be best to rewrite the first paragraph to
just say something like this:

   The protocol and implementations MUST process non-orthogonal requests
   in the order in which they are received.  Any two requests are
   non-orthogonal if and only if the reordering of the two requests does
   not change the final state on either the server or client side.

Comments?

/Tobias

[Please CC me any comments, since I'm not on the list!]

---

From: Simon Tatham <[email-masked]>
Date: Sun, 10 Feb 2002 11:26:38 +0000

Tobias Ringstrom  <[email-masked]> wrote:
> responses.

But both are true, though, surely?

If I submit a read request covering bytes 0-100, then a write
request covering bytes 20-120, and then a read request covering
bytes 40-140, then _both_ the following restrictions apply:

 (a) The requests may not be processed in a (perceptibly) different
     order. That is, the first read must be performed before the
     write (so that it returns the unmodified pre-write data) and
     the second read must be performed after the write (so that it
     returns the modified post-write data).

 (b) The responses to the requests _also_ may not be reordered. Even
     if the three requests have different serial numbers and an
     alert client could plausibly be able to deal with the responses
     arriving out of order, it is not permitted to send them that
     way.

Of course, if I submit a read request covering bytes 0-100, then
another covering bytes 50-150, there's nothing in theory to stop the
server from actually performing the reads in the opposite order, or
even doing a single read covering bytes 0-150 and returning two
substrings of it.

I don't see what's unclear about the wording as it is.
-- 
Simon Tatham         "Every person has a thinking part that wonders what
<[email-masked]>    the part that isn't thinking isn't thinking about."