Subject: Re: [hybi] Random Responses

From: Mridul Muralidharan <[email-masked]>
Date: Mon, 13 Apr 2009 00:45:39 +0530 (IST)

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

> From: Jamie Lokier <[email-masked]>
> Subject: Re: [hybi] Random Responses
> To: "Mridul Muralidharan" <[email-masked]>
> Cc: "Mark Lentczner" <[email-masked]>, "Greg Wilkins" <[email-masked]>, [email-masked]
> Date: Sunday, 12 April, 2009, 11:59 PM
> 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.

The usecases discussed are not one request/response per socket case, but a significantly longer (in time) channel - so the setup overhead mentioned would not be that significant.
For simple request/response, http is fine - for really really simple (few bytes) request/response, even http can be quite an overhead, but that is not the point :-)

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

I think you are assuming a request/response modal - where in server does not 'read' next request until previous one has been processed and response sent ?

Consider the following needs :

a) Multiple widgets talking to server and vice versa - so, hopefully, sharing connection. (else the cost if really high in terms of number of connections, etc)
b) Not limit to just request/response based modal, but also including event/notifications which dont require an ack..

Not to mention corner case handling like error detection/recovery due to abrupt connection loss, etc.

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

Please see above.

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

See above on why this might be needed in HTTP case too.

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

Use of XML, though sensible, is just part of BEEP framing.
Not sure why XML parsing is an issue, but we can always replace it in other means to carry metadata - for example, the meta-data getting exchanged is representable in HTTP header form too imo (*) - 

http style headers (if required) \r\n
raw content

(*) The headers could include both the framing rules and flow control rules. Since I was not involved in BEEP design, or not very intimately involved in using BEEP, not if this is a valid assertion though.)

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

Yes, this might be the key issue - getting it to inter-operate might outweigh other considerations, atleast initially.
This was probably the only reason why we stuck had used BOSH's long poll based approach to other possibilities.

Regards,
Mridul

> -- Jamie

      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 21:09:53 +0100

Mridul Muralidharan wrote:
> The usecases discussed are not one request/response per socket case,
> but a significantly longer (in time) channel - so the setup overhead
> mentioned would not be that significant.

No, it's the latency per BEEP channel, not socket.  BEEP channel setup
involves a requests "give me a channel please [+XML profile]", and
response "here's your channel [+XML profile]".  Then you're allowed to
send your real request over the channel.

The trouble is you need a separate BEEP channel for every potentially
overlapping message.

> I think you are assuming a request/response modal - where in server does not 'read' next request until previous one has been processed and response sent ?

No, I'm not.  I'm firmly in the asynchronous messaging (interleaved
without arbitrary size limits and ACKs optional) camp :-)

> a) Multiple widgets talking to server and vice versa - so,
hopefully, sharing connection. (else the cost if really high in terms
of number of connections, etc)
>
> b) Not limit to just request/response based modal, but also
including event/notifications which dont require an ack..

Yes, I'm talking about those sort of things, over a single socket.

With BEEP you need separate channels (not sockets) for every message
which may be multiplexed with other messages, whether there's a
response or not.  You can't start those BEEP channels just by using
them: first you have to request them all.  To multiplex messages
independently, ou don't know how many channels you need in advance, so
you request them on demand and that's the extra delay from BEEP.

Multiplexed HTTP proposals are much better: to start a new channel,
you just pick a new channel number and send a message using it.

> due to abrupt connection loss, etc.

I'm deeply familiar with such things.

> > If you imagine a bi-directional HTTP (easy because requests and
> > BEEP-style flow control.  (I have implemented this).
> 
> Please see above.

Agreed.  The point is interleaving (multiple in-flight independent
messages) is what makes per channel flow control needed.
Bi-directionality by itself doesn't, but bi-directionality by itself
is much less useful (like the RHTTP proposal).

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

Yes it is, when we let messages be interleaved with each other.  It's
interleaving which makes the requirement for per channel flow control.

Interleaving, by the way, is important to support large messages (like
video files, say) which don't block small messages.  Without
interleaving we'd force each application developer to produce their
own splitting and sliding window protocol whenever they _might_ have a
large message, which is silly when we can do it in the protocol nearly
for free.

> Use of XML, though sensible, is just part of BEEP framing.

BEEP framing is simple, a short bit of text, I like that.  I'm quite
surprised they followed tidy, sensible IETF text protocol traditions
in the framing and then used an XML envelope in one of the essential
protocol elements.

> Not sure why XML parsing is an issue,

Many devices which parse HTTP right now don't have XML parsers.  Think
HTTP proxies, HTTP firewalls, and client devices with 16kB of memory.
XML parsing is not hard, but it's not trivial either.  Having to skip
the optional DTD whose syntax is not precisely defined in the XML spec
does not help.  Having to accept multiple charsets in a basic ASCII
protocol does not help either.

It would be nice if new messaging protocol were understandable by such
devices too, and it's probably quite important that the basic framing
is understandable to proxies and firewalls.

> but we can always replace it in other means to carry metadata - for
example, the meta-data getting exchanged is representable in HTTP
header form too

I agree that HTTP header form or similar is better than an XML
envelope, for the basic protocol anyway.  Of course specific
applications are welcome to use XML, JSON etc. inside the protocol
envelope.
 
-- Jamie