Subject: Re: [hybi] Random Responses

From: Mridul Muralidharan <[email-masked]>
Date: Sun, 12 Apr 2009 18:12:57 +0530 (IST)

Yes, BEEP does fit the requirements discussed so far ... (not to mention support for flow control which becomes immediately necessary in bi-directional streams).

Flip side would be, I am not sure if it is upgradable from HTTP with current infrastructure - other than through CONNECT that is.

Regards,
Mridul

--- On Sun, 12/4/09, Greg Wilkins <[email-masked]> wrote:

> From: Greg Wilkins <[email-masked]>
> Subject: Re: [hybi] Random Responses
> To: "Mark Lentczner" <[email-masked]>
> Cc: [email-masked]
> Date: Sunday, 12 April, 2009, 7:57 AM
> 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 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.
> 
> BEEP!
> 
> > 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
> 
> 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:
> > 
>    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.
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
> 

      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 12 Apr 2009 19:29:00 +0100

Mridul Muralidharan wrote:
> Yes, BEEP does fit the requirements discussed so far ...

BEEP doesn't meet the requirement for simple implementation because it
requires every implementation to parse XML.  HTTP does not.

Also BEEP's per-channel setup latency is rather large: one redundant
round trip.  Using BEEP for a simple HTTP request would take noticably
longer than HTTP itself on high latency networks.

> (not to mention support for flow control which becomes immediately
> necessary in bi-directional streams).

BEEP's flow control is sensible, but that's not the reason for it.

For bi-directional streams, TCP/IP's built in flow control is enough.

If you imagine a bi-directional HTTP (easy because requests and
responses are easily distinguished), it does not need any BEEP-style
flow control.  (I have implemented this).

BEEP-style per channel flow control is needed because of its ability
to multiplex multiple channels in the _same_ direction on a single
TCP/IP stream.  Without per-channel flow control you get deadlocks or
infinite buffering needed in some practical uses.

Unfortunately BEEPs per channel flow control is sensible, but it's per
channel setup is expensive both in needing XML and in network round
trip time.  It would be good to keep the flow control but use smarter
channel setup.

> Flip side would be, I am not sure if it is upgradable from HTTP with
> current infrastructure - other than through CONNECT that is.

It's not, but all protocols discussed can be overlaid onto the current
infrastructure using the HTTP hacks we use today (long GET etc.),
while giving new proxies the chance to recognise the overlaid protocol
and participate in it properly (dropping the hacks, proxying better).

Imho it would be good to discuss how we can overlay any new protocol
that we're talking about compatibly onto the existing HTTP infrastructure.

-- Jamie