RE: An opes usage question.

On Tue, 9 Mar 2004, Krishna Ramadas wrote:

> 	Perhaps, the recommendations that you make about using the
> current definitions within OPES are applicable. I understand that
> you are recommending the use of the "tracing" facility and the "meta
> data transfer" facility.

Kind of, but not exactly. Sorry for not being clear. I used the
tracing facility as an example. The primary purpose of my response was
to remove load balancers from any high-level architecture discussion
on this thread as an irrelevant detail.

In other words, I was trying to argue that any diagram that shows a
load balancer is too low-level for the current discussion; and that
load balancing, when done right, should not affect the protocols being
discussed (including tracing and notification protocols).

> Utilizing the "tracing" mechanism for flow discovery can work for
> HTTP. [...] The problem is with other applications.

Yes, each application protocol needs its own tracing profile and some
application protocols will not be able to support embedded tracing at
all.

> Meta Transfer is established as a requirement in the document
> "Requirements for OPES callout protocols (3.13)". Are you also
> implying that we embed meta-data in the traffic flow, just like
> trace information?

Not really. The best solution would depend on environment/application
specifics that we do not know yet. Transferring small amounts of
metadata embedded in HTTP messages is usually OK, but probably not
always the best approach, and we may not be dealing with HTTP here.

> Often, processing of meta-data is done in a background
> thread and not in the main thread for gaining processing efficiency. I
> had, therefore, understood that OCP should provide the
> meta-data-transfer support. Is this correct?

OCP provides support for metadata exchanges. However, my understanding
is that the question of whether OCP should be used among described
proxies is still open.

> Transferring meta-data using OCP also becomes tricky when the
> callout and proxy roles are mixed within one physical entity,
> especially with load balancers separating the proxy stages.

I am not sure what complications or tricks you are referring to. Since
OCP establishes roles on per-OCP-connection basis, I am not sure why
mixed proxy roles would cause a problem. Said that, we do not have an
OCP profile for proxy-to-proxy exchange, so it is difficult to
speculate about the benefits and limitations of such approach. In
theory, OCP can marshal any mix of data and metadata, but it may not
be the best protocol to use among proxies, depending on the specifics
of the environment.

> BTW, the billing servers may never be in the traffic path like it is
> shown in the figures that we have been discussing. Instead, two
> stages of adaptation servers may be separated by load balancers.

True. However, if proxy-to-proxy exchanges are not tied to persistent
connections/pipeline, then it probably does not matter, as far as
proxy/flow identification is concerned? Am I missing something?

Alex.

>                   ContentServer
>                         |
>                  BillingServer
>                         |
>                    AdaptServer
>