On Thu, 17 Apr 2003, Marshall Rose wrote:
so, when i say:
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
you seem to be replying that this won't work because you can't have more
than one message in flight on a single channel.
yes.
correct. so if the requirements is:
- asynchronous request/response where the response can start coming
back before the request is fully sent.
use the approach i explained above. if there is an additional
requirement that:
- more than one simultaneous asynchronous request/response on a
single beep session
then do each parallel exchange on its own channel.
if there are other requirements, or these requirements are wrong, let me
know.
Simplified transport requirements of the current OCP core, in each
flow direction (processor to server and server to processor), are:
- efficiently send possibly large application messages and
metadata (blobs), with possibly more than one blob being
sent at a time; parts of each blob should be
delivered in sent order
- send usually small OCP "control" messages related
to the dataflow above, at any time; control messages should
be delivered in sent order
We agree that the first approach (one channel per OCP connection) does
not work without hacks because it does not support the "at any time"
part.
Using multiple channels per OCP connection (one for control and one or
more for data/metadata) would work, but, as I said, I am worried about
synchronization problems between data and control channels. My
understanding is that BEEP does not guarantee that two messages sent
on two channels will arrive in the order they were sent. Please
correct me if I am wrong.
This FTP-like approach adds more state than is strictly necessary for
OCP, but I cannot think of any specific OCP task that would _require_
synchronization between data and control channels. So, yes, I think it
can work. Moreover, adding extra control channels to support fast
aborts is on the todo list and the FTP approach would make that
optimization a little easier to describe.
I think we are on the same page now. It would be great to hear from
others as well. Is anybody able to follow my lame attempts at
explaining the problem? Does anybody have horror stories to tell about
FTP (other than firewall problems)? Is there a reason we should not
use multiple BEEP channels per OCP connection _if_ BEEP is selected as
a transport protocol?
Marshall, is it correct to say that opening a new BEEP channel can be
"cheap", even if we want to use encryption and such? Multi-channel
solution appears to be more elegant than my hack, but I am worried
about the cost on performance. If an OCP connection (all BEEP
channels) needs to be encrypted using, say TLS, does it mean that an
OCP agent would have to re-negotiate encryption parameters for every
channel it needs to open? This is not a show-stopper (because we could
keep channels persistent), but we need to understand the costs. It
would be nice if we could say "and for this new channel, use the same
parameters we negotiated for that old channel", but we cannot do that
in general, can we?
Thanks,
Alex.
P.S. Apologies for skipping a few steps in the previous e-mail. I
put too many new details in one example.