Re: Asynchronous BEEP draft status

On Wed, Nov 26, 2008 at 7:07 PM, Thomson, Martin
<[email protected]> wrote:
> Hi David,
>
> I went through exactly the same thought process in coming up with this solution.  I think that only the conclusion is different.
> RFC 3080 allows for interleaving split ANS frames.  It doesn't say why.  I can't for the life of me work out how this would be a good idea.
>
> My view is that there is no reason why a stack should treat ANS frames any
> differently to other frames once they are received from the application.  Frame splitting is a flow control and throughput issue, which should be handled at a lower logical layer in the stack.

In below, "message" means a *complete* MSG, RPY, ERR, or ANS, not a frame.

Interleaving of ANS frames provides a useful feature not commonly
implemented by toolkits other than beepcore-c.

AFAICT, several toolkits (beep4j, for example) started off only
working in terms of messages, for both send and receive.

This doesn't allow a peer to process data as it arrives in frames, and
can cause deadlock if the window fills. So, eventually they allow
frames to be received by applications as they arrive, perhaps
optionally (vortex will accumulate all frames into a complete message,
if requested, for example, before presenting them to an application).

It is quite useful to expose frames to applications on the sending
side, too. For example, it allows a single RPY to have an arbitrarily
large size, so an entire file could be transferred in a single RPY
(ANS, MSG, etc.) in block-size frames.

All the toolkit APIs since beepcore-c (that I've seen) force the
application to present the entire payload of a MSG, RPY, ANS, etc. as
a contiguous chunk of data in a single API call when sending.

Anyhow, RFC3080 describes MSG/ANS as a one-to-many exchange, and each
one of the entities on the "many" side is allowed to generate its ANS
as a series of frames. Without this capability, the entities would be
forced to provide complete ANSs serially, instead of in parallel.

Sam