ietf-openproxy
[Top] [All Lists]

Re: BEEP as OCP transport

2003-04-17 15:47:08

On Thu, 17 Apr 2003, Marshall Rose wrote:

ok, do you care that they actually got there or not?

I know they would get there because I use lossless transport (I would
be notified if something goes wrong). I do not care about the timing
though (because it is a pipeline/stream). I am only interested in the
adapted data sent back; that adapted data may come at any time, even
before [some of] my original data reaches the other end(!)...

not true. when TCP fails, a really good API will tell you the last
octet that got acknowledged. most APIs just tell you the connection
was broken.

... and the latter is all OCP agent needs to know.

what this means is that the *only* way that an application protocol
knows what application data was successfully received is for it to make
those determinations based on the application data it receives.

An OPES processor does not care whether the original data was received
(in general). It only cares about the adapted data it receives back.
Thus, if connection is terminated abnormally, the adapted flow is
incomplete and that is all that matters.

A callout server cares even less because it cannot influence what OPES
processor does with the adapted data. If a connection is terminated
prematurely, the callout server simply forgets about corresponding
transactions.

for example, that's a reason why an SMTP sender waits to get an
acknowledgement to the final "." of a DATA command.

True, but such an acknowledgement is not needed in the OCP data
pipeline case, I think.

What I would have to do with BEEP is:

    Processor(client): server-can-start(MSG)
    Server: processor-can-start(MSG)
    Processor(client): start(ANS), data-have(ANS), data-have(ANS)...
    Server: start(ANS), data-have(ANS), data-have(ANS)...

or some variation of the above.

why not use beep's segmentation capability?

beep's MSG, RPY, ERR, and ANS messages each contain a single MIME entity,
e.g., an application/octet-stream or whatever.  beep segments a MIME
entity into multiple frames. each frame, except the last one, has an
indicator saying "more to come".
    ...
the only "tricky" part is that if the server replies with an ERR
instead of a RPY, then the client must send a frame without the
more-to-come indicator and the sender must start ignoring frames
that refer to the errored MSG (cf., section 2.6.3).

This would be a very good solution but BEEP core says (emphasis mine):

   When a message is segmented and sent as several frames, those frames
   must be sent sequentially, WITHOUT ANY INTERVENING FRAMES FROM OTHER
   MESSAGES ON THE SAME CHANNEL.  However, there are two exceptions:
   first, no restriction is made with respect to the interleaving of
   frames for other channels; and, second, in a one-to-many exchange,
   multiple answers may be simultaneously in progress.

This means that OPES agent cannot interleave data-have messages with
other messages without incurring the penalty of an extra three BEEP
messages. If OPES agent want to send a non-data-have message
immediately, on the same channel, in the middle of a data-have stream,
it would have to

  Extra 1. "Close" the current data-have "stream" with "MSG ."
        2. send the non-data-have message
  Extra 3. "Reopen" the data-have "stream" with "MSG *"
  Extra 4. receive "NUL" response for "Extra 1".

The extras can be avoided if non-data-have message is sent on a
different channel, but then we have synchronization problems to worry
about.

Hmm... A combination of the more-bit and other-end-can-send approaches
may be an attractive hack though (but still a hack, unfortunately).
Once again, we seem to be beaten by a strange asymmetry in BEEP:
interleaving ANS "responses" is allowed, but interleaving MSG
"requests" is not.

Did I miss anything?


Thank you for helping with the OCP/BEEP transport mapping.

Alex.

<Prev in Thread] Current Thread [Next in Thread>