Re: Some general SPDY feedback / questions

On Wed, Jul 18, 2012 at 2:03 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> 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.
>

Even that one has its problems. What happens when the connection is for
multiple domains?
Is there a separate sequencing for each domain (that'd make sense as that
is what happens for HTTP).

In the end, I think that idempotent/non-idempotent determination by method
has become so polluted as to be unworkable, and applications should
probably just figure it out themselves by controlling when the requests are
issued (which is what they do today).
-=R


>
> --
> 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.
>
>