On Tue, 15 Apr 2003 at 16:57:04 -0600 (MDT) Alex Rousskov announced:
> If I am reading things correctly, the requirements allow several
> "connections" over one transport connection, but OCP forbids it.
> Is there disagreement? If not, which notion is correct?
OCP Core does not forbid several OCP connection over one transport
connection (bugs notwithstanding). OCP Core says, in part
("Connections" section, blob 87):
If BEEP over TCP is used, than a BEEP channel will correspond
to a callout connection, allowing callout connection
multiplexing over a single TCP connection.
What made you think that "OCP forbids it"?
These words:
For example, if raw TCP is the transport, than a TCP connection
will correspond to a callout connection.
> The requirements mention "keep-alives" and "heartbeats". Was there
> any intent to require heartbeat support? OCP does not use them,
> which is fine with me.
OCP Core supports heartbeats via <i-am-here> and <are-you-there>
messages. Those are actually very useful because OCP Core relies on
timeouts to resolve possible problems with overloaded or
malfunctioning agents and timeouts without heartbeats do not work well
for "slow" adaptations.
I think "heartbeat" generally means that a message every n time units is
required - there's no "are you there".
> Reviewing the messages on this list, I find myself deeply uncertain
> about what would be in "OCP/HTTP bindings". Would it be an encoding
> of the OCP protocol elements (transaction start, transaction id,
> etc.) as HTTP-style headers?
You may be confusing/mixing OCP transport binding and
application-specific drafts. We have not decided on OCP transport
binding. In theory, it can be HTTP like in ICAP. If that is the case,
then either OCP Core (if there is only one transport binding) or HTTP
Transport Binding for OCP (if there are multiple transport bindings)
drafts will indeed document how to convert OCP protocol elements to
HTTP elements.
Then there are two distinct options being considered, as you say:
1. A single transport for OCP.
2. Multiple transports for OCP.
If there is a single transport, then there will be a single document
showing how to encode the OCP protocol elements into bitstrings carried over
that transport.
If there are multiple transports, then there will be a document for each
transport showing how to encode the OCP protocol elements into bitstrings
carried over that transport. Those would be OCP/HTTP, OCP/RTP, OCP/TCP,
OCP/BEEP, perhaps. With other possibilties, such as OCP/SNMP. OCP/FTP,
OCP/WEP, ....
Lurking in the wings is the idea of a new transport, call it OCPTRAN for
the moment (or "copper" :-) see later), running over one or more of
TCP, UDP, IP, BEEP?, ...
The OCP document as it stands now is a data model and state machine. It is
awaiting WG decision on the issue of transport.
OK so far?
One thing that might help with clarity is to note that we have been
talking about using a Layer 4 transport as OCP transport sometime, but
other times we are talking about using a Layer 5 protocols as an
OCP transport.
What bothers me is the issue of the nature of the proxied protocols
and whether or not each one needs its own OCP binding. We know that
HTTP, with only minor modifications, can be the OCP transport for a
proxied HTTP connection. Can/should it be the OCP transport for FTP?
For SNMP? For telnet? That possibility is what led to the awkward
architecture for protocol conversion, using OCP transport X for requests
and getting the reply back on transport Y!
There are pros and cons here. Using a "native" callout protocol (HTTP
over HTTP, SNMP over SNMP, RTP over RTP, etc.) is a quick way to get
going - the person who knows the protocol can probably figure out a
quick way to get the callout protocol implemented, the framing and
other issues are simpler if you aren't changing protocols, libraries can
be reused, etc. The con is that the OPES processor may become bogged
down with too many pieces of client-side code. There must be other
issues.
If there is only one transport protocol, then it may become
complicated with too many features as it tries to encompass all the
different framing methods, reliability issues, etc.
My opinion is that if we decide on only one transport, that it *not*
be tied to HTTP, that it be as lightweight as possible. (By the way,
I'm in touch with someone who says he's got documented timings of the
overhead involved in parsing a null XML message with standard commercial
software - 30 times the effort of a simple TCP connection sending one
byte back and forth; I'm trying to get his tech report).
Personally, I think the best choice is a new transport named OCPTRAN that can
run over TCP for data that needs reliable service and can also run over
UDP or just IP if need be. I'm not sure where BEEP fits in this taxonomy -
it seems to be orthogonal (in the sense of "not a branch point" rather than
"useless").
> I cannot keep myself from stumbling over "application message" time
> and again. And again. The stuff between the OPES processor and
> callout server that might be encapsulated data coming from or going
> to the proxied transaction ... can that have an unambiguous name,
> like "zinc", if there's nothing better?
Except for section 1.1, there should be no mentioning of "proxied"
anything. The fact that OPES processor is a proxy is out of OCP scope,
and section 1.1 attempts to document that. "Application message" is
whatever OPES processor and callout server what it to be, essentially.
I would not like "zinc", but would very welcome better alternatives to
describe an undefined (content, metadata) pair.
Even if the draft doesn't refer to proxied data, the concept is still
there, and "application message" will continue to seem ambiguous, to
me, anyway. How can you not like "zinc"? OSERVICE-BLOB?
OUTBOARD-SERVICE-DATA?
Hilarie