Re: [hybi] Random Responses

[Jamie Lokier <[e-mail]>]

Mridul Muralidharan wrote:
> > 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.

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

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

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.

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

I'm deeply familiar with such things.

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

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.
> 
> See above on why this might be needed in HTTP case too.

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.

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

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