[BEEPwg] Asynchrony and BEEP

Thomson, Martin Martin.Thomson at andrew.com
Wed May 21 02:09:57 PDT 2008


Hi Francis,

Thanks for the response.

I am taking an existing protocol and binding it to BEEP.  Using two
separate channels in the fashion you describe is only possible if I
wanted to (or was able to) change the protocol payload.  Currently, the
protocol is bound to HTTP.  The idea was to move to BEEP to allow for
increased throughput.  However, the method you suggest requires that
request/response correlation is performed at a higher layer than BEEP.
This either requires modification of the application protocol, or
insertion of another protocol layer.  This is either infeasible or
unpalatable.

As far as your comments go, I had a little trouble correlating each
comment with my original statements.  Apologies if I've misinterpreted
anything you've said.  I'll reply inline below.

Francis Brosnan Blazquez:
>
> Now, I would like to comment some assertions you have done:
> 
> 1) (Please see 3.4 and 4.1 of [1]) The technical reason to make
> intra-channel processing to be serial is because it is the most widely
> available request/response model in use today. Thus, it is required to
> be represented in BEEP, mainly because people use it. You say it is
> used
> in some cases (????) but it is by far the most popular model used in
> connection oriented escenarios (like HTTP).
> 
> However, what makes BEEP different, is that channel pipeline is *not*
> the only one invocation model. You can use several channels or use
> ANS/NUL replies semantic to implement independent exchanges.
 
In response to 1) I'd say that your reason is not technical at all.  I
have no problem with someone making the decision to be serial and for
the reason to be no more than personal preference.  As for the rest, see
my above comments.

> Channel pipeline is a *core* BEEP feature, well understood and well
> perceived by people using BEEP. What you are proposing is a protocol
> change that have also consequences in what also makes BEEP different
> and
> useful: how it is handled session close.

I examined this in some detail - there is no change required to how a
close is handled.  A peer is expected to wait until all outstanding
requests are complete before responding to a close request for each
channel.  Session/connection close is rejected when there are open
channels.  Neither would need to change if full asynchrony were enabled.

> 2) Saying channels suffer "head-of-line" is quite inexact. I believe a
> protocol can suffer "head-of-line" when there is no alternative (like
> HTTP). BEEP channels have several already available and well supported
> invocation options to specifically avoid "head-of-line".

I'll restate: an individual BEEP channel suffers head-of-line in the
same way that an individual HTTP connection suffers head-of-line.  The
same workarounds apply to each.  For instance, I've seen your suggested
workaround standardized for an HTTP application.

You could consider this misleading, so I'll qualify the statement: BEEP
is less crippled by this for a number of reasons.  A BEEP channel is
more lightweight than a TCP connection and you are less susceptible to
problems like intermediate NAT.
 
> 3) Maybe this could change in the future, but at this moment, features
> and profiles can only extend BEEP function giving semantic but never
to
> modify base BEEP protocol defined at RFC3080 (maybe I'm wrong but I
> believe this is the essence).

The IANA registry lists no features, so it is hard to make any statement
about what can (or can't) be achieved with them.

If you never need to rely on modified/extended RFC 3080 behaviour,
profiles could do everything you could want to do.  Logically then,
features are reserved for where the base 3080/3081 specifications come
up short and something extra is needed; something that a profile can't
do, like changing or adding to control channel message semantics.

> 4) Message number is not only used for protocol errors, but also to
> give
> the notion of unique and identificable transaction (which is, again,
> commonly required), and to allow APIs to reply to a particular
message.

If message number was removed from the specification, BEEP would still
work.  Replies must be provided in the same order that the requests were
made.  Request/response correlation can be performed entirely through
message ordering.  Therefore, message number is entirely redundant.
Beep4j (the API I am most familiar with) doesn't even look at the
message number for replies, except when checking for protocol errors. 
------------------------------------------------------------------------------------------------
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]




More information about the BEEPwg mailing list