[Top] [All Lists]

Re: OCP transport nomination

2003-04-25 13:50:40

On 20:32 25/04/03, Markus Hofmann said:
Alex Rousskov wrote:
Do we expect the set of callout servers to change so rapidly that
server connections cannot be reused at the OPES processor? If yes, we
may have to support UDP-like OCP transport (and probably change a lot
of OCP requirements related to "OCP connections"). If no, then
transport connection setup time is not an issue and TCP-based OCP
transport should work as well (or better) as UDP-based one. I think
the latter is much closer to reality. Am I missing something important

No, I don't think you're missing anything. You summarized very nicely what my understanding has been for a while. Since we expect to "re-use" estbalished TCP connections between OPES processor and callout server, the TCP connection establishment overhead is probably not of big importance.

As indicated before the first need I can see is for a pre-resolver. Draft not completed: I consider OPES for the job.

1. User enters a DN with a TLD
2. the OPES processor filters on the TLD
3. if unknown string ask call out server(s) if it is an internationalized scripting or an existing TLD
4. if yes, corrects and auto-generates the filter + possible change
5. if not, potentially caches the filer (memory size dependant) and may be denies the call

Looks very similar to DNS current traffic to me.
1. if the OPES is in front of the ISP nameserver TCP support to one server seems OK. 2. if it is in front of the resolver I understand that OCP would not be a good choice (fast occasionial needs)
Is that correct?

I note that if several call out servers are to be polled, UDP seems a need (I am not good on TCP/UDP)?

<Prev in Thread] Current Thread [Next in Thread>