Re: [hybi] Random Responses

[Mridul Muralidharan <[e-mail]>]

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

> From: Jamie Lokier <[e-mail]>
> Subject: Re: [hybi] Random Responses
> To: "Mridul Muralidharan" <[e-mail]>
> Cc: "Mark Lentczner" <[e-mail]>, "Greg Wilkins" <[e-mail]>, [e-mail]
> 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/