W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Some general SPDY feedback / questions

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 18 Jul 2012 21:45:59 +0000
To: Roberto Peon <grmocg@gmail.com>
cc: James M Snell <jasnell@gmail.com>, ietf-http-wg@w3.org
Message-ID: <9913.1342647959@critter.freebsd.dk>
In message <CAP+FsNcGECC1ybR9TKG64tdAs1huPM2jHgLL2kt8Sh7E_07XZQ@mail.gmail.com>
, Roberto Peon writes:

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

We actually dont need to specify that do we ?

If the two domains are independent, their transactions will not
interefere with each other as they end up in different places.  If
the are dependent, presumably they will end up the same place, and
the sync=yes will DTRT.

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

(= option 3 "make it undefined")

Yes, that is the simpler solution, but if we are serious about
shaving RTTs it is not a good choice.

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:46:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC