Re: Some general SPDY feedback / questions

In message <CABP7RbfFj__CeriiJA-caEda_h0K5b__oj6-zYRuA=BgSofuhA@mail.gmail.com>
, James M Snell writes:

>2. Just for the sake of clarity, what is the expected behavior if a
>user-agent interleaves multiple modification requests to the same resource?
>For instance:
>
>   => SYN_STREAM(id=1,:method=PUT,:path=/my/resource)
>   => SYN_STREAM(id=2,:method=DELETE,:path=/my/resource)
>   => SYN_STREAM(id=3,:method=POST, :path=/my/resource)

This is entirely parallel to the same issue with respect to
tagged-queueing of requests to a disk drive and remote filesystem
operations.

You basically have three choices:

1. Make it automatic.

   Any non-idempotent operation is a synchronizing/stalling event
   that prevents reordering of other operations across it.

   The following request stream will always execute seqentially
   in this case:

   => SYN_STREAM(id=1,:method=GET,:path=/my/resource)
   => SYN_STREAM(id=2,:method=PUT,:path=/my/resource)
   => SYN_STREAM(id=3,:method=GET,:path=/my/resource)
   => SYN_STREAM(id=4,:method=DELETE,:path=/my/resource)
   => SYN_STREAM(id=5,:method=GET,:path=/my/resource)
   => SYN_STREAM(id=6,:method=POST, :path=/my/resource)
   => SYN_STREAM(id=7,:method=GET,:path=/my/resource)

2. Give the requestor a synchronizing primitive.

   Basically allowing the client to say "don't reorder anything
   across this marker, but continue to optimize on both sides"

   The following request stream will always execute seqentially
   in this case:

   => SYN_STREAM(id=1,:method=GET,:path=/my/resource1)
   => SYN_STREAM(id=2,:method=GET,:path=/my/resource2; sync=yes)
   => SYN_STREAM(id=3,:method=GET,:path=/my/resource1)

   (Notice that you can sync on an indempotent operation, this
   is deliberate, as it allows "cheap" NOP-sync operations.)

3. Leave the behaviour undefined.

   It's anyones guess what will happen.

In a web where client-side is non-participating in application logic
(ie: the good old fill-the-form-press-submit model), any of these
will do.

But we are increasingly seeing web-apps that actively participate
in, and have deep knowledge of the application logic on the
server side.

For those, number one is the safe choice, but it pessimizes needlessly
and number three will cost RTT's because the client has to wait for
operations to complete before issuing dependent operations.

That leaves the second option, and given the cheapness of implemenation
(You tag all requests with a generation number which increases after
every sync-tag, never sort higher generation before lower.) I think
that is the most future-proof choice for HTTP/2.0.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 18 July 2012 21:04:15 UTC