Thinking of your last response I come back on a few point.
I will try to make the selling - target could be septembre thought.
At 23:51 23/05/03, Alex Rousskov wrote:
On Fri, 23 May 2003, jfcm wrote:
On 18:43 23/05/03, Alex Rousskov said:
>
> > Here is my interpretation of the primary part of your problem:
>
> I am afraid I was not clear enough. The system exists. It runs well
> and is designed to have A respondng B an XML status report. This is
> all what A knows doing. It checks the calling IP address and
> respons. This permits B to discover that A has a problem from the
> daily status report. The only improvement is that A will call when
> it has a problem (an empty XML message).
I do not think the above details affect correctness of my response.
> > A emits messages using format/protocol pA
>
> Yes. Empty XML.
>
> > A is configured to talk D as its "next hop" for pA
>
> It calls B. But because it uses IP addresses, the address listed as
> B has to be D address. Or better - but how will that work. D fakes
> being B.
A talks to D. Whether D represents, fakes, or forwards messages to B
is of no importance at this point. D is the "next hop" for A, using
pA.
> > B is interested in A's state but understands
> > (or prefers) messages in format/protocol pB, not pA
>
> Yes. The message is unique. A full A XML status report
>
> > D accepts messages in pA from A,
> > D adapts messages in pA to messages in pB, possibly using C,
> > D forwards adapted messages (in pB) to B
>
> Yes but you by pass all what is interesting:
> - multiple sending in one very long cession
I already commented on that: OCP supports multiple adapted responses
and OPES must not prohibit them.
> - possible changes in who is C
Not a problem from OPES/OCP point of view, as long as D and C can
handle that. For example, D can close the existing OCP connection to
C1 and establish a new connection to C2, transparently for A and B.
> - necessary calls from C to A to be able to complete the service
> on the pA to B call.
I already commented on that: this is not prohibited by OPES but is
beyond OPES scope. In other words, C is free to do that, using
whatever means necessary.
This is the point. Relation between A and D and D and B woul dbe http.
As thay are toway. EVERY relation betweeen D and C should be OCP.
Several reasons:
- homogenity
- security (one single port)
and
- money (this is where I could get the money for the development) :-)
My main interest is to see up to where OCP may be used.
> > C is in a different administrative domain than D
> >
> >An OPES system can support the format/protocol adaptation above, IMO.
> >OCP already handles the case when one message from A is converted to
> >multiple messages to B (to address your concern #3).
>
> - even if it is a "long cession" are there no timers anywhere
> which may influence?
OCP timeouts are not defined yet, but will be fully
configurable/negotiable, of course. The duration of an OCP connection
does not matter from OCP point of view (as long as all OCP agents
involved are OK with long-lived connections).
There may be some interesting things one can do on transport level to
make long-lived OCP connections efficient and robust (e.g., smooth TCP
connection termination and resumption using custom OCP messages).
yeap. The interest is that the dispatcher (D) would serve as a kind of
signaling. It caould be called by applications to know if the OPES
service par C is closed. In case of a reboot, that would be of use to
know what is underprocess.
> - no impact if there are reboots of D?
No impact from OPES/OCP point of view. However, raw TCP may not be
appropriate transport for OCP in this case, and D has to be able to
keep state across reboots. These are not OPES/OCP issues though. These
are issues for D state storage and for OCP transport.
Problem is that this keeping of state (see above) should be maintained
on D, C, B to reinitiate the situation in the case one or two reboot.
In a way this would be documented bt B not having received the end of the
cession.
> >The other part of your problem is communication in the other direction
> >(B, D, and C talking to A). I believe such communication is not
> >prohibited by OPES rules, but otherwise is outside of OPES scope.
>
> - problem in having them totally supported under OCP you would
> think of?
OCP does not know of these "communications in the other direction". If
A, B, D, and C want to use OCP for "communication in the other
direction", they can. I am not sure it would be the best choice
though. Don't they already have a protocol that B, D, and C use to
query A? Perhaps I misunderstand your question/concern?
B querries A.
D comes in the between. So speks http bothe ways.
C speeks OCP with D.
No other relation. When C calls A itis through D (they are not in the same
domain! D is its gateway).
> Interest is that if I got the funding it might help developping OCP
> functions and test them. Also, to put me back in the OCP stuff (I am
> out of scope right now with the load with my ICANN oriented load).
> Low chances to get a budget, so is it worth a try? Or are there
> enough resources already commited in here?
Are you kidding? There are never enough resources! If you get funding
and will be willing to share money and/or results, the group will
benefit, of course. For example, it can speed up building a decent
reference implementation.
This was my idea from the begining. So I am looking for netservices which
could do the trick. One si the DNS application. But quite political to know
about it. Europe could pay but the project is heavy.
Here the idea that I could have a grant of 50% of the development if I find
a regular customer because it is R&D. Lot of paperwork and delays. Unless
someone was interested in sharing? The money would come from the French
Natinal Agency fo Research. But again there may be some much paperwork and
delays that it would be very heady and the customer getting tired. I will
try however when I have a good understanding of the whole OCP.
Is there not any other French on this list?
jfc
Alex.
> >On Fri, 23 May 2003, jfcm wrote:
> >
> > >
> > > I come across the following customer request. I think it may help
checking
> > > OCP can be used and can support this.
> > >
> > > There are four systems involved.
> > > 1. A: an automated system (oil station pump)
> > > 2. B; a remote management station
> > > 3. C: a considered ticketing service
> > > 4. D: a possible OPES
> > >
> > > B polls A once a day
> > > When A has an incident it calls B.
> > > But B is management not support
> > >
> > > So the idea is D as an OPES between A and B branching into C via OCP.
> > >
> > > 1. when A has a problem, the call is blocked by D and C is told.
> > > 2. C manages the incident (may take hours)
> > > 3. when the incident has been repaired, C can authorize D to
forward the
> > > call as "treated".
> > >
> > >
> > > I would like to understand if all this is orthodox as far as OCP
which will
> > > be used between D and C.
> > >
> > > 1. is there a problem about qualifying this as an OPES?
> > >
> > > 2. A only knows to say "I have a problem" and to report its status upon
> > > request from B (IP address) and respond.
> > >
> > > D's IP would replace B's IP in A table. So the dialog would
actually
> > > be A-D.
> > > So, if B and C call, D should make the calls coming from D.
> > >
> > > there are three reasons to call A:
> > >
> > > - normal administrative calls by B
> > > - calls by D when receiving the alarm: to check the reason of
the call
> > > (D may decide to discard if it is a repetitive call)
> > > - calls be C: as part of the ticketing status control and
reporting to
> > > technicians
> > >
> > > Calls by D and C are part of the OPES service. Is that dialog
with the
> > > caller permitted?
> > >
> > > 3. there would be a need for a multiple "continuations" of A calls
to be
> > > received by B.
> > >
> > > Sequence:
> > > - A calls to say I have a problem : this is the data
transmitted that
> > > is going to be modified.
> > > - B should receive that data as a continuity of different
blocks, may
> > > be over hours
> > > - 1st block: there is an alarm info to follow
> > > - 2. this alarms has been taken over by the ticketing service
> > > - 3. the ticketing service may pass different reports
> > > - 4. report "the problem has been addressed as follows: ...."
> > >
> > > 4. what is also interesting is that A, B, D are in the same domain of
> > > security While C is an externalized service. So OCP relations would
have to
> > > be secure. Also, C may change into C1, C2, etc as the
complexity/type of
> > > incident management is handled.
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 19/05/03