Re: BEEP as OCP transport

On Thu, 17 Apr 2003, Alex Rousskov wrote:

> A combination of the more-bit and other-end-can-send approaches may
> be an attractive hack though
Here is how it might look (C == OPES processor, S == callout server)

        // Processor allows the server to start a BEEP ANS stream
        C: MSG 1 1 .
        C: ; perhaps no payload at all
        C: END

        // Server allows the processor to start a BEEP ANS stream
        S: MSG 1 2 .
        S: ; perhaps no payload at all
        S: END

        // normal OCP flow starts for the processor
        // (when it receives "MSG 1 2 .") and then ends
        C: ANS 1 3 .
        C: ...
        C: END
        ... // some of the ANSes may use multiple frames
        C: ANS 1 1234 .
        C: ...
        C: END
        C: NUL

        // normal OCP flow starts for the server
        // (when it receives "MSG 1 1 .") and then ends
        S: ANS 1 4 .
        S: ...
        S: END
        ... // some of the ANSes may use multiple frames
        S: ANS 1 1235 .
        S: ...
        S: END
        S: NUL

The last two group of messages do not depend on each other from BEEP
point of view. This is still not perfect because it prevents OCP from
using BEEP MSG number/concept for anything useful. However, this
allows to package OCP messages inside BEEP ANS messages, with
virtually no overhead.

This is clearly an abuse of BEEP, to get around its assumptions about
message exchange styles. However, this allows (hopefully) to reuse
other BEEP mechanisms such as channels, profile negotiation, and
session encryption.

I would not be surprised if the above can be polished further to allow
for more tight OCP:BEEP integration.

Alex.