Re: [hybi] BWTP Proposal - Bidirection Web Transfer Protocol

[Greg Wilkins <gregw at webtide.com>]

Jamie Lokier wrote:
> Greg Wilkins wrote:
>> So if you have traffic that is substantially one way, you end up
>> sending lots of empty messages the other direction to keep things
>> balanced.
> 
> It's not immediately obvious, but BWTP will send empty messages in the
> other direction anyway.
> 
> They are called TCP ACKs, and you'd be surprised how little difference
> a few "200 OK" lines makes per ACK, if they are piggybacked properly.
> 
> (Of course they aren't always piggybacked properly.)

Wow - it's like listening to myself when I defend long-polling vs streaming :)



> I'm curious about that.  What known issues are there with
> intermediaries and pipelines?  I'm aware of lots of problems with
> origin servers and pipelines, but not intermediaries.

A good example is apache modproxy, which is request based
and will not forward another request until it has a response
from the last forwarded.

> RFC2616 specifies that under certain conditions, a connection must be
> terminated _abruptly_ when an error response is sent to certain
> requests like POST, to stop a potentially large request from being
> sent whole.  Any pipelined requests after it will be lost, but you
> cannot know which ones the server received and started processing.

I'd really like to have graceful shutdown supported, so that any
party (including intermediaries) can close a connection without
any message loss.   Of course this does not stop unexpected
closures.

> You have, thankfully, already addressed the orderly shutdown problem.
> Real HTTP servers use a lingering half-closed socket, to ensure the
> last response will actually reach the client if the client pipelined
> another request.  This is necessary for reliable behaviour (due to a
> TCP quirk), yet not mentioned in RFC2616.

I still think BWTP needs a little bit more, so that an intermediary
can initiate a graceful shutdown.  It's not enough for it to just
inject a Connection:close message, as a message may arrive from the
other direction.   So I think there needs to be a Connection:closing
message.


and from your prior email:

> I agree, except by dropping HTTP entirely after the negotiation, it
> does implicitly suggests you need multiple connections if the complex
> things, like authentication, need to be different for separate
> back-end processes.

BWTP gives the choice of per connection default or per message headers.

It would be feasible to have each message carrying an authentication
header to be differently authenticated from other messages.

But generally more thought is needed on the whole security/Origin issue.

cheers