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