[BEEPwg] Asynchrony and BEEP

Thomson, Martin Martin.Thomson at andrew.com
Wed May 21 20:42:19 PDT 2008

More inline,

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

Debating the advantages of serial processing, while entertaining, isn't
relevant to the discussion.  I am putting forward a different use case.

I'm not attempting to invalidate serial processing; far from that.  I am
only pointing out that it isn't always the best approach.

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

I don't see how polling is necessary - I have implemented out of order
receipt of messages in beep4j with a change of only about 5 lines of
code without a need for polling.

> >
> > I examined this in some detail - there is no change required to how
> > 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
> 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.

That's not the case.  The number of items that would need to be tracked
is exactly the same number as the number of channels required if channel
pooling were used:

  N = number of requests each section * average time required to process

No matter what protocol option you choose, the state maintained at the
serving peer doesn't change - it still has to process all those
requests.  Therefore, tracking is only necessary at the requesting end.
Of course, it would also be reasonable to place an upper bound on the
total number of outstanding request.  New requests could block or be
rejected locally when this limit is reached.


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

Feature negotiation guarantees that backward compatibility is retained.
Unless both peers understand (and accept) the changed functionality,
nothing different happens.  No "baroque" mechanisms or other strangeness
would be necessary.
> > > 4) Message number is not only used for protocol errors, but also
> > > 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
> > 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.

I think that you have missed my point.

How an API tracks message number is not really relevant to the

Regardless of what the replying peer does, the requesting peer sees all
replies in the same order as the requests it sent.  Request/response
correlation can be performed by matching the order of replies to the
order of requests.  Therefore, the message number is not useful for
anything other than error detection.

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

I'll agree.  But that's purely an implementation consideration.  Of
course, allowing this makes the API implementation more complex.  A
complexity that wouldn't be necessary if out of order responses were
allowed.  Interesting data point: beep4j doesn't enforce ordering of
replies at the replying peer; it's actually easier this way.

> Again, this is an implementation issue which is not considering
> practical consequences.
> An API not allowing to reply to a particular message using a
> msgno is causing to shift the logic of keeping track about the moment
> 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
> delivery. I find this quite problematic.

No tracking would be necessary if out of order responses were allowed.
The application is (and should always be) unaffected by the change.

Allowing out of order responses actually makes the logic at the replying
peer simpler.


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.

More information about the BEEPwg mailing list