[BEEPwg] Asynchrony and BEEP

Francis Brosnan Blazquez francis at aspl.es
Thu May 22 00:47:47 PDT 2008


> Hi Francis,

Hi Martin,

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

Certainly. Maybe you can use a MIME header to flag the payload with a
transaction number.

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

Ok.

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

Ok. Looking at the request/response model as a natural evolution from
the local function invocation, it is clear that order matter.

You invoke the function/service looking for some result/resource, which,
with great probabilities will be used for next invocations, or to stop
current flow if an error occur. That's why you need the serial nature
(and the reason why it is widely present in other protocols). 

More than a technical reason, I see an implementation issue. Most of
languages used to write networked applications do it by invoking
functions in order and according to the results they perform. 

Now, moving the focus to the other side. Assuming an our of order
scenario, this will require the caller to push its request into
something like a pool of pending request, and to poll frequently if the
request was satisfied. I don't know how do you see this, but I found
quite complex and unnatural to make it as the default behaviour, not
only in BEEP, but in any connection oriented protocol.

More than a technical reason, I find here a practical implementation
decision.

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

Again, this is a implementation issue which is not considering practical
consequences for a BEEP stack. 

Currently, an easy approach for a BEEP stack is to have the
last_{replied,received,etc} value to guide the connection close process,
which involves all channels opened at the moment. 

Your proposal will cause that all channels over all connections to have
to keep track of virtually 2^31 items (either because they are missing
or because there were received). This applies not only to messages
pending, but for pending replies.

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

Certainly...

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

... this is not the point.

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

Ok, but BEEP isn't a special case. As other RFCs, most of
changes/extensions I've found, they were done in a way previous
implementations remains working. A particular interesting case is MIME
(See historical note, page 3, from RFC2045).

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

Ok.

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

I don't agree. In fact the limitation for replying in order only applies
to BEEP internal function. 

User application on top of a BEEP stack should be able to reply in any
other (another question is that the reply may be retained until
condition is meet, but definitely this should be handled by the BEEP
implemetation). 

Again, this is an implementation issue which is not considering
practical consequences. 

An API not allowing to reply to a particular message using a particular
msgno is causing to shift the logic of keeping track about the moment a
reply can be done from the BEEP stack into the user application. That
is, the application on top of such stack will have to ask the API "can I
reply?"; if not, the application will have to store the reply for later
delivery. I find this quite problematic.

Cheers!

-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.



More information about the BEEPwg mailing list