thanks for the clarification.
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.
that is correct, channels on the same session, are effectively
parallel. if you need to synchronize them, you can, you have to define
messages to do so for your protocol.
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?
if the answer is "FTP", then the wrong question has been asked.
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?
each beep session has a single encryption/authentication context. you
negotiate it at the start of the session, and it applies to every
channel thereafter, e.g.,
beep channels
beep frames
tls packets
tcp segments
all traffic on all channels goes over the same tls session.
/mtr