Re: [hybi] Is there a traffic jam?

["Thomson, Martin" <[e-mail]>]

Hi Mark,

I don't have any opinion either way on the suitability of BEEP, other than to remark that it seems wasteful to retread old ground.  The conclusion might be subtly different; it might look like web-sockets, or it might be entirely different.

That's by-the-by.  As others have stated, more benefit might be gained by clearing the way for people who might like to use their own protocol.  Then they can make their own trade-offs.

I can perhaps dispel a few myths about BEEP though:
 
> As pointed out, BEEP has many attributes that make is seem a likely
> candidate for this space.
> 
> But, to summarize (and add to) the points against it:
> 
> Seems that each request/response would need its own BEEP channel. This
> is because of the synchronous nature of BEEP channels(*). Channel
> creation is mid-weight, but at least requires a round-trip before the
> actual request could even begin. It might be possible to encode the
> request within the channel creation request, but there is a 4k payload
> limit for such messages.

[[MT]] BEEP does pipelining, just like HTTP.  Of course, the synchronous restriction is artificial, and there are use cases that demand a greater degree of asynchrony.  Hence, the draft you refer to.

> BEEP requires both XML and MIME parsers. Note that BEEP messages are
> not equivalent to HTTP messages.  BEEP has no address (URL) or method
> for the messages, and the headers of BEEP are MIME, whereas the
> headers of HTTP are not. One could imagine using the message/http MIME
> type to an HTTP message as the payload within a BEEP message. But then
> you'd need XML, MIME and HTTP parsers... This personally doesn't
> bother me, but it is getting rather heavyweight for something small.

[[MT]] The "XML" parsers I've seen in implementations of BEEP are rarely as complex as you make out.  The control channel doesn't demand much complexity of a parser.  Now you can take that as an indication of the maturity of BEEP implementation if you like, I can't disagree about _that_ point...

> There is no addressability in BEEP for channels or messages. I see two
> ways two add one to a profile: 1) Add the address (and perhaps method)
> as fields in the initialization message on channel create. This would
> require a new channel for every request. 2) Encode the address in each
> message (see above for using message/http)

[[MT]] If you are looking to interact with the same resource, identifying the resource at channel creation time might make sense.  Alternatively, the MIME headers can be used to identify a resource for each request.

However, this as a problem for a certain set of assumptions.  This set of assumptions might vary greatly depending on your application.
 
> Some unclear aspects:
> 
> The overhead of BEEP seems like it would greater, though I admit I
> haven't calculated it. I doubt it would be outrageous.

[[MT]] Greater than websockets?  That seems quite likely.  Depends on how much you are using from of what BEEP offers.

> I don't know enough to know if flow control internally would be
> needed. If so, BEEP has it.  If not, it is a little scary to implement!

[[MT]] If you want to avoid implementation, it's not actually that hard to send an occasional SEQ frame.  It's quite easy to avoid flow control being a problem.  However, I'll note that flow control in current implementations isn't like that - a small fixed window is common, which severely limits throughput.  Of course, that's a further sign of stack maturity more than anything else, there is nothing in the protocol preventing bandwidth-delay product estimation.  

--Martin


------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]