On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote:
On Tue, 15 Apr 2003 at 16:57:04 -0600 (MDT) Alex Rousskov announced:
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.
which is true unless we want to add connection IDs to OCP. Without
explicit connection IDS it is not possible to have multiple OCP
connection over a transport connection that does not support embedded
"channels" or "sessions".
I would be happy to add connection IDs if needed, but it may be a good
idea to decide on the transport binding(s) first in case we decide on
a single binding that makes connection IDs unnecessary.
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".
Yes. OCP agents can implement heartbeat by sending <i-am-here>
messages at regular time intervals if desired. I do not see a need to
make that a default/required behavior though. Do you?
> 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, ....
Yes, that is exactly what I was trying to say. In case of a single
binding, there is probably no need for a separate "transport"
document -- everything transport-related can be integrated into OCP
Core.
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?, ...
Exactly :-)
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?
Yes, we are in agreement.
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.
I will add such a note to the Core draft.
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!
I agree that proxied protocols may benefit from a particular OCP
transport. That would be the primary argument to support multiple
transports.
However, IMO, HTTP makes a very poor OCP transport regardless of the
proxied protocol. HTTP is simply not designed for that. I can provide
specific arguments if anybody cares to listen. I think ICAP suffers a
lot in clarity (and, perhaps even features/performance) due to an
unfortunate choice of transport. Martin will probably disagree. I
think BEEP is a much better fit. I do not have a strong opinion about
this though (yet?).
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.
I disagree that framing is simpler. I agree that learning curve is
less steep and that [good] libraries can be reused. I would address
the learning curve issue by selecting a very simple transport/encoding
model. I would address the code reuse issue by selecting a
well-supported (existing) or very simple (new) encoding.
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.
Or, it might be too simple to support some esoteric corner cases
efficiently. I would strive for the latter rather than designing a
transport "behemoth".
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.
I agree. That is what makes raw TCP or perhaps BEEP attractive to me.
(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).
I would be very interested to see this report because I am surprised
by the conclusion. Perhaps "standard commercial software" means
"unoptimized commercial software" (in which case I would not care much
-- general-purpose parsers can be slow and I bet the TCP stack they
used had been optimized many times).
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 hear you, but when I read
http://www.clipcode.com/peer/beep_technical_whitepaper.htm
I feel guilty for not using BEEP and inventing yet another *TRANP. I
have not finished reading or digesting the paper though. If by "not a
branch point" you mean "we would still need to decide on BEEP
transport (BEEP over what)", then I agree.
> 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.
Yes.
How can you not like "zinc"? OSERVICE-BLOB? OUTBOARD-SERVICE-DATA?
"Blob" is close. What do you call a blob tuple (metadata + data)?
Blot? Blop (for blob pair)? Plob (for pair of blobs?)
Alex.