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.
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.
for example, that's a reason why an SMTP sender waits to get an
acknowledgement to the final "." of a DATA command.
... 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".
in many cases the entire message fits into one frame, e.g.,
C: MSG with some data & no more-bit
S: RPY with some data & no more-bit
if it doesn't fit into one frame,then:
in most applications, the server waits until it receives a frame without
the more-to-come indicator before processing the data, e.g.,
timeline 1
----------
C: MSG with some data & more-bit
C: some data & more-bit
C: some data & more-bit
C: some data & more-bit
C: some data & no more-bit
S: RPY with some data & more-bit
S: some data & no more-bit
however, the server can start processing the MSG as soon as it receives
the first frame, even if the more-to-come indicator is present:
timeline 1 timeline 2
---------- ----------
C: MSG with some data & more-bit
timeline 2 starts
S: RPY with some data & more-bit
C: some data & more-bit S: some data & more-bit
C: some data & more-bit S: some data & more-bit
C: some data & more-bit S: some data & more-bit
C: some data & no more-bit S: some data & no more-bit
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).
/mtr