Subject: [hybi] Random Responses

From: Mark Lentczner <[email-masked]>
Date: Wed, 8 Apr 2009 17:23:23 -0700

Sorry about the hodge-podge here: After IETF-74 I had a zillion things  
to do at work, so it wasn't until this morning that I was able to  
fully catch up on my backlog of reading hybi mail. Here are a number  
of bit-and-bobs that I wanted to reply to:

> the whole point of bidirectional communication is that it's not a  
> request-response model.
Actually, I don't agree. At Linden Lab, we've seen a great need for  
bidirectional communication that is request/response model.

> IMHO, is that it be possible to implement the server-side in a few  
> dozen lines of code, and I don't see any way to implement a  
> compliant HTTP server and client in such a small code footprint.
We've successfully implemented rHTTP server and client components in  
just a few dozen lines of code because we are able to just reuse the  
existing HTTP client and server components that exist in the  
environments we work in (C++, Python).

> The rHTTP proposal is more attractive as a wire protocl as it uses  
> normal HTTP framing and should be trivial to implement with existing  
> code bases. However, rHTTP would not significantly change bayuex  
> long polling other than to make long-poll responses into real  
> requests and long-poll requests into real responses. The same data  
> framing and latency would go over the wire. The semantic that is  
> missing from HTTP that would improve Bayeux/cometd is the ability to  
> send multiple responses to a single request. If for example, a 1xx  
> response could be sent with headers and content without terminating  
> the current request, then bayeux long-polling would avoid the need  
> to issue another long-polling request. This would reduce data  
> overhead and avoid protocol induced worst case latency.

I think this statement is worthy of greater study!  While I don't like  
overloading the 1xx responses... It seems to me that this is speaking  
to the crux of the matter:Many of us like HTTP framing, but want only  
one TCP connection, and asynchrony of request and response, in both  
directions. I feel a draft in here....

> What would you consider normal HTTP style framing here? What would  
> HTTP framing give you that isn't available with the framing  
> currently proposed with Web Sockets?

Addressing (URLs), Headers, Content specification, Transfer  
specification, Status

	 - Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: Ian Hickson <[email-masked]>
Date: Thu, 9 Apr 2009 00:34:22 +0000 (UTC)

> bidirectional communication that is request/response model.

I misspoke, I should have said that the point of full-duplex communication 
is that it's not request-response -- either side can spontaneously send a 
message.

> > dozen lines of code, and I don't see any way to implement a compliant 
> > HTTP server and client in such a small code footprint.
>

Sure, if you can use libraries then implementing any protocol is trivial. 
The point is that the protocol should be simple enough that one doesn't 
need to rely on libraries to get a compliant implementation.

> > HTTP framing give you that isn't available with the framing currently 
> > proposed with Web Sockets?
> 

The socket in WebSocket can be (indeed, must be) addressed via URL.

At the message level, why do we need to force those features on all users? 
They seem like features we should allow people to have if they want, but 
they don't seem like features we should require all clients and servers to 
implement just because someone might want them.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Apr 2009 08:45:31 -0600

> need to rely on libraries to get a compliant implementation.

Where does this requirement come from? I have never seen a similar
requirement in any RFC.

And are you assuming that developers should be able to implement this
protocol without any libraries whatsoever? Not even for TCP, UTF-8, or
anything else?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mark Lentczner <[email-masked]>
Date: Thu, 9 Apr 2009 09:06:23 -0700

> is that it's not request-response -- either side can spontaneously  

Then I mis-replied. I should have said that we have a need for full- 
duplex request-response -- either side can spontaneously send a  
request message, and either side can, when ready, reply to a prior  
request.

> need to rely on libraries to get a compliant implementation.

I'm not sure you understood my point: We weren't using rHTTP  
libraries, but extant HTTP libraries. You had made prior comments  
about the ease of implementation, which as a practical consideration,  
I agree is relevant. There was indication that you thought other  
proposals in this space required complex implementations. I was  
pointing out that our rHTTP experience was quite the opposite: Just a  
few lines of code to get all the features of request/response  
messages. That we were able to reuse ubiquitous HTTP libraries I think  
is precisely to the point.

> The socket in WebSocket can be (indeed, must be) addressed via URL.

Only the establishment in WebSocket is addressed via URL.  In rHTTP  
each request can be addressed by URL.  This is useful as it is a very  
common piece of meta-data that applications want. For example, using  
WebSockets, for any complex page, an application is almost certainly  
going to want a way to address which widget on the page is the  
intended recipient of the event. Hence, each application is going to  
have to devise an addressing scheme, and more importantly, a method of  
encoding that address in the simple string event.

> implement just because someone might want them.

Of course, but you must recognize there is a trade-off here that all  
protocols make. The design needs to choose a feature set wide enough  
that many different applications can make use of it, but must do so  
balancing complexity and overhead. For example, WebSockets has chosen  
to support both binary and UTF-8 payloads. The overhead of the lead-in  
type byte was seen as worth it, even though there are many  
applications that will only use the UTF-8 strings. So, I see the  
choices here as just a matter of degree. I think popularity of HTTP  
for many kinds of applications has shown that one or more features of  
HTTP(*) are often applicable to an application's needs, while the  
overhead of these features is low enough to be worth including them in  
the protocol for all.(**)

	- Mark

(*) Addressing (URLs), Method, Headers, Content specification,  
Transfer specification, Status
(**) I imagine the wire overhead for putting a minimal string event  
into an HTTP message would be something like:
	POST / HTTP/1.1
	Host:
	Content-Type:text/plain;charset=UTF-8
	Content-Length:xxx

and
	204 ACK

That's 96 bytes overhead for a 100 to 999 byte payload. Seems high,  
but for the usage cases that web pages present, this probably is not  
relevant.  Further, once one has this framing, it is very likely that  
rather than build addressing into the string payload, applications  
would just make use of the URL field. Plus, this framing already has  
character encoding support.

The overhead in code is certainly more than parsing a single sentinel  
delimited string. However, the ability to parse an HTTP message is  
well understood, easily implemented, and nearly ubiquitously available.

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden

---

From: Mike Dierken <[email-masked]>
Date: Thu, 9 Apr 2009 21:23:33 -0700

Using HTTP framing for these request/response messages is an  
interesting idea and something I like a lot, especially when the  
request receiver is on the user's machine.

On Apr 9, 2009, at 9:06 AM, Mark Lentczner <[email-masked]> wrote:

> about the ease of implementation, which as a practical  
> consideration, I agree is relevant. There was indication that you  
> thought other proposals in this space required complex  
> implementations. I was pointing out that our rHTTP experience was  
> quite the opposite: Just a few lines of code to get all the features  
> of request/response messages. That we were able to reuse ubiquitous  
> HTTP libraries I think is precisely to the point.
>
> each request can be addressed by URL.  This is useful as it is a  
> very common piece of meta-data that applications want. For example,  
> using WebSockets, for any complex page, an application is almost  
> certainly going to want a way to address which widget on the page is  
> the intended recipient of the event. Hence, each application is  
> going to have to devise an addressing scheme, and more importantly,  
> a method of encoding that address in the simple string event.
>
> balancing complexity and overhead. For example, WebSockets has  
> chosen to support both binary and UTF-8 payloads. The overhead of  
> the lead-in type byte was seen as worth it, even though there are  
> many applications that will only use the UTF-8 strings. So, I see  
> the choices here as just a matter of degree. I think popularity of  
> HTTP for many kinds of applications has shown that one or more  
> features of HTTP(*) are often applicable to an application's needs,  
> while the overhead of these features is low enough to be worth  
> including them in the protocol for all.(**)
>
>    - Mark
>
> relevant.  Further, once one has this framing, it is very likely  
> that rather than build addressing into the string payload,  
> applications would just make use of the URL field. Plus, this  
> framing already has character encoding support.
>
> The overhead in code is certainly more than parsing a single  
> sentinel delimited string. However, the ability to parse an HTTP  
> message is well understood, easily implemented, and nearly  
> ubiquitously available.
>
>
> Mark Lentczner
> Sr. Systems Architect
> Technology Integration
> Linden Lab
>
> [email-masked]
>
> Zero Linden
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Paul Prescod <[email-masked]>
Date: Fri, 10 Apr 2009 12:33:52 -0700

On Wed, Apr 8, 2009 at 5:34 PM, Ian Hickson <[email-masked]> wrote:
> ...

He's not talking about random libraries. He's talking specifically
about the libraries required to implement Web browsers and Web Server
*already*.

As someone else pointed out, if we presume no libraries then TCP,
UTF-8 and URLs are all intimidating standards that Web Sockets pulls
in "by reference". Nobody objects because we all know that libraries
for these are very widely deployed in Web systems. HTTP is also in
that category.

 Paul Prescod

---

From: Paul Prescod <[email-masked]>
Date: Fri, 10 Apr 2009 12:57:06 -0700

On Wed, Apr 8, 2009 at 5:23 PM, Mark Lentczner <[email-masked]> wrote:
> Sorry about the hodge-podge here: After IETF-74 I had a zillion things to do
> at work, so it wasn't until this morning that I was able to fully catch up
> on my backlog of reading hybi mail. Here are a number of bit-and-bobs that I
> wanted to reply to:
>
> the whole point of
> bidirectional communication is that it's not a request-response model.
>

I am curious what you typically put in responses to messages from the
"central server" to a browser running on an edge device.

I'd also be curious whether you expect the response to be provided by
Javascript or by an underlying layer that just says: "yeah, I got the
message: I'll pass it to Javascript when that thread is available."

As I think about it today I wonder if it is really helpful for the
server to wait for a response from the client, which it will typically
ignore (IMO).

 Paul Prescod

---

From: rektide <[email-masked]>
Date: Sat, 11 Apr 2009 13:20:59 -0400

On Thu, Apr 09, 2009 at 09:06:23AM -0700, Mark Lentczner wrote:
> duplex request-response -- either side can spontaneously send a request 
> message, and either side can, when ready, reply to a prior request.

I'd inject that a "worthy" transport also has to be able to permit either side to ad-hoc
initiate communication at any time as well.  I'd also say either end must be able to opt to
never reply without violating the transport spec.

How the reader dices this is anyone's guess: is this is a request-response transport with
optional reply, or is this a event transport with optional request-reply? I dont think it
matters, I think a good transport ought to support both.

> Only the establishment in WebSocket is addressed via URL.  In rHTTP each 
> request can be addressed by URL.  This is useful as it is a very common 
> piece of meta-data that applications want. For example, using  
> going to want a way to address which widget on the page is the intended 
> recipient of the event. Hence, each application is going to have to 
> devise an addressing scheme, and more importantly, a method of encoding 
> that address in the simple string event.

Addressability to the client side is something I had not considered before.  I would be very
interested to hear how this would work in a collaborative environment, how the server would
deal with multiple clients.

When I was heavily investigating Bayeux, I often thought each client should have a service
channel to enable cross system addressability.  I never had a concrete API sketched out for
how the endpoint would function, just the notion that there would be a URL template for
talking to clients.

> balancing complexity and overhead. For example, WebSockets has chosen to 
> support both binary and UTF-8 payloads. The overhead of the lead-in type 
> byte was seen as worth it, even though there are many applications that 
> will only use the UTF-8 strings. So, I see the choices here as just a 
> matter of degree. I think popularity of HTTP for many kinds of 
> applications has shown that one or more features of HTTP(*) are often 
> applicable to an application's needs, while the overhead of these 
> features is low enough to be worth including them in the protocol for 
> all.(**)

Agreed, I think HTTP's framing is well worth the cost.

-rektide

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 12 Apr 2009 12:27:26 +1000

Mark Lentczner wrote:
> 
>  I should have said that we have a need for 
> full-duplex request-response -- either side can spontaneously send a 
> request message, and either side can, when ready, reply to a prior request.

BEEP!

> for any complex page, an application is almost certainly 

BEEP!

 > I think popularity of HTTP for many kinds of
> (*) Addressing (URLs), Method, Headers, Content specification, Transfer 
> specification, Status

BEEP!

> (**) I imagine the wire overhead for putting a minimal string event into 
> an HTTP message would be something like:
>     POST / HTTP/1.1
>     Host:
> That's 96 bytes overhead for a 100 to 999 byte payload. Seems high, but 
> for the usage cases that web pages present, this probably is not 
> rather than build addressing into the string payload, applications would 
> just make use of the URL field. Plus, this framing already has character 
> encoding support.

BEEP!

Generally agreeing with all your points.  Yet the attributes you
describe do sound pretty much like BEEP protocol - or at least
beep framing.

BEEP is very much a HTTP style protocol with addition of
bidirectionality, multiple response requests and multiple
channels over a single connection.

If BEEP was extended with a few default assumptions (eg
UTF-8 text body if no content type specified), then it would
approach the byte efficiency of websocket, while preserving
the extensibility and flexibility of HTTP.

If the security and authentication aspects of BEEP were
stripped, then a pretty simply protocol would remain.

IF I was forced to pick a winner.... then I'd certainly
look very closely at BEEP or a BEEP derivative.

cheers

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 12 Apr 2009 22:32:57 +0100

> channels over a single connection.

Yes, although BEEPs channels are unnecessarily expensive (in latency)
to create on demand.

> look very closely at BEEP or a BEEP derivative.

I've looked closely at BEEP for this, and I agree, BEEP has some very
good things which should be copied.

Unfortunately its channel setup is expensive (latency, not bandwidth),
and often you'd want a channel per message in flight.  That forces you
to either accept the channel setup latency, or queue messages behind
each other in the same way that HTTP pipelining forces messages to
block behind each other.  Neither is ideal.

There is a BEEP extension to create sub-channels on demand without
having to request one, which is closer to ideal behaviour when you
have a new message to send.  But it unnecessarily constrains the
ordering of messages.  (I asked the author to relax this, but he
didn't see any point for his applications and suggested there are
other protocols to choose from if I need that.  I don't see the point
in the constraint.)

What I think would be ideal, and it's been mentioned already as
"asynchronous HTTP", is:

    HTTP or simplified-HTTP message headers and body.
    Bidirectional - either side can send requests and responses.
    Channel id attached to each message.
    Chunked encoding, with channel id attached to each chunk.
    Per channel flow control exactly like BEEP over TCP profile.
    Request/response id attached to each message.
    Request/response id matches responses out of order to requests.
    Pure messages with no response allowed, using "no-response" r/r id.
    All the above features are optional.

When you make those features optional, it degrades gracefully to
HTTP pipelining, then to HTTP persistent connections.

Also by making features optional, it is much easier to implement just
the subset of features you need, or plug in a feature-complete
implementation when you need all of them.

That provides the message/event protocol some people are asking for,
and also provides the request/response protocol some people are asking
for, does both bidirectionally, and over a single socket, and with
multiple applications sharing the same socket if they want.

It's efficient too, if you regard HTTP as efficient.  They're about
the same overhead.  Latency is sometimes better than HTTP, because it
doesn't have pipeline blocking like HTTP.  Proxy buffering
requirements are about the same as HTTP, in particular they are
bounded similarly.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 12 Apr 2009 22:43:43 +0100

> request message, and either side can, when ready, reply to a prior  

I agree.  HTTP requests and responses are easily distinguished, so
it's quite simple to accept either.

Recovery behaviour when the connection disappears is tricky if you
have HTTP-like requests.

Right now, clients tend to send non-idempotent requests (i.e. POST) on
a new connection, because if you send to a persistent connection, and
the socket reports an error, you don't know if the request was
received and processed and then the network died, or if the server
timed out the persistent connection and closed it while you were
sending the request.  You can't tell the difference, and it's unsafe
to repeat the request, so you use a new connection.

With a bidirectional connection, typically the initiating client sets
everything up, then the server is able to send a request - but this is
analogous to sending a request over a persistent HTTP connection.

In general with this sort of network protocol, you define a recovery
process - or assume the system will recover naturally - or don't have
non-idempotent requests coming from the server end.  But if we're
claiming to support HTTP in both directions, then we need to define if
the server is allowed to send POST requests and such to the client,
and what to do realistically on seeing network errors.

> encoding that address in the simple string event.

I agree that the URL address space is a very common useful piece of
metadata.  There is so much built around it now; it makes sense to
provide applications with that.

I also agree that HTTP message frame parsing is readily available, and
easy to implement when it isn't.

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 13 Apr 2009 10:23:31 +1000

Jamie,

excellent information and insight in this and your other messages.

I think it is very valuable to look at existing protocols like
BEEP and to identify/enumerate their deficiencies. Straw men
are useful (and others probably appreciate not having me
continue to use websocket for that purpose :)

I've tried to capture a lot of this recent conversation on the
wiki: http://trac.tools.ietf.org/bof/trac/wiki/HyBi

I've added a new section called "Candidates Requirements" where
I list/describe the attributes of a protocol that people have
identified as good (although there is no consensus if all are
indeed good and/or needed).

For each proposal I've listed some pros and cons, mostly
against candidate requirements.    It would be good if others
could sanitize those for any biases coming from me.

I've also added a "Asynchronous HTTP" proposal based on the
description you gave.   You allude to existing proposals for
such a thing - do you have references to those?

cheers