[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3.3 Bounded Latency
On Mon, 2002-01-14 at 12:32, Doug Royer wrote:
> I see the usage of multiple BEEP commands for a single
> CAP command (as in from initiation to completion of operation),
> not in the spirit of BEEP.
Your initial proposition could be fixed. I think it makes very
interesting use of the an ANS message. However the draft-06 approach
seem to have more advantages.
> I think that the MSG/ACK..ACK...NUL
> reflects that the fact the command is still in progress.
Conceptually both approaches uses a REQUEST/ACK,ACK,ACK/RESPONSE.
It's the definition of ACK that differs:
In your suggestion (correct me, if a donn't understand it
ACK = 1. ANS "timeout" from the CS (advantage of using same msgno).
2. MSG "continue" from the CUA on a different channel +
3. RPY from CS.
ACK = 1. MSG "timeout" from CS
2. RPY "continue" from CUA (same channel).
If we consider a basic scenario without a preemptive abort. Then
the draft-06 approach have the following advantages.
1. Minimize the number frames.
2. It's clearly stated by BEEP that for every MSG there is
an associated response. As a consequence a BEEP compliant
CUA MUST respond to a timeout request, and the channel
waiting for the response will not freeze forever.
3. All the message flow are sent over the same channel.
4. Depending on the usage, the channel that receives the
continue/abort may be busy. The delay impacts the channel
processing the request that generated the timeout.
With the draft-06 approach it's the CUA receives the timeout
message. A CUA MSG queue is likely to be empty (only used for
timeout), and the RPY from the CUA is not queued on the
> And as a BEEP implementations should support 257 concurrent channels,
> sending the continue or abort on one of those other channels
> pretty much is a no-op.
257 are probably more than enough, but they do take some resources
on the server. I don't see why we should encourage inter-channel
communication when not necessary.
> > While converting CAP to BEEP, we came up with the following
> > solution: use a different channel to cancel commands (inter-channel
> > communication is asynchronous).
> > - Hard to explain/document.
> What's hard? - send command on separate channel.
You sold me, let use the inter-channel communication for
> > - Draft-05 had the same limitation
> > (even though enhancements were discussed on the list).
> No. In fact the only limitation was if pipeline was set to 1,
> else it did not have that limitation.
I checked draft-05, and you're correct.