[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: BEEP as OCP transport
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
> 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
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.