Re: [hybi] Random Responses

[Mridul Muralidharan <[e-mail]>]

--- On Mon, 13/4/09, Jamie Lokier <[e-mail]> wrote:

> From: Jamie Lokier <[e-mail]>
> Subject: Re: [hybi] Random Responses
> To: "Greg Wilkins" <[e-mail]>
> Cc: [e-mail]
> Date: Monday, 13 April, 2009, 3:02 AM
> Greg Wilkins wrote:
> > 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.
> 
> Yes, although BEEPs channels are unnecessarily expensive
> (in latency)
> to create on demand.

Please see below.


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



What I seem to be missing here is the need to create a BEEP channel for each request/response. That would definitely be expensive (probably unusably so).

What I am thinking of is, if the channel creation becomes more 'application' oriented - as in, one channel per widget/app/other granularity on top of the beep channel - then wont we not have a better usage ?
Kind of like, various widgets on a page sharing the same underlying BEEP session each using its own channel to communicate to server (I think DOJO's comet protocol did have some notion of channels when I had glanced at it a couple of years back).


Non-async request/response within a beep channel is similar to pipelining in http - unless previous request is processed and response sent, the next is not handled - or did I miss something here ?
The sync behavior is per channel - it is async across channels.



So I guess it depends on how the channel usage is modeled - as you and others mentioned, if each request/response is going to be a new channel, the costs of setup and the latency could be very high - but if we 'prescribe' some rules or suggestions of channel usage - then the cost becomes pretty low for long running channels.


Note that I am not actively advocating BEEP (though it might look that way :-) ), it is just that BEEP seems to me to be designed for and already handles a bunch of the usecases mentioned here.
A few things we might drop could be - tls, if already over http, SASL - if already authenticated http session, etc - the resulting profile could be pretty lightweight (and might address the latency issues).


If the client requirement issue is a problem (need for xml, etc), it might be worthwhile to think about alternative framing rules.


Regards,
Mridul






> 
> -- Jamie
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
> 


      Cricket on your mind? Visit the ultimate cricket website. Enter http://beta.cricket.yahoo.com