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
here?
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)?
jfc