On Fri, 25 Apr 2003, jfcm wrote:
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
Though I am not sure what you mean by "auto-generates the filter +
possible change", the above does not seem to fit OPES model nicely.
You are talking about a query/response or RPC interface with the
callout server: "is it an internationalized scripting?" While
everything can be viewed as a form of an RPC interface, OPES is
specializing in _adapting proxied traffic_.
It is possible to adjust the above so that it fits OPES better:
...
2. the OPES processor forwards the DNS query (with a questionable DN)
to a callout server
3. the OPES processor receives a possibly adapted query from the
callout server
...
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.
Yes, though I would rather describe OPES processor as a part of an
[ISP] nameserver to fit OPES model better; recall that OPES processor
is a proxy/hop on the application protocol path, a DNS server in this
case.
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?
What do you mean by "front of the resolver"? How is that different
from "front of the ISP nameserver"?
Fast occasional use is OK as long as both agents are able to keep TCP
connection(s) between them open. If they cannot (for whatever reason),
then "fast occasional use" would require UDP-like transport.
I note that if several call out servers are to be polled, UDP seems
a need (I am not good on TCP/UDP)?
The number of servers is not relevant as long as it is reasonable
compared to the capacity of the OPES processor. For example, one can
serve thousands of concurrent TCP connections efficiently on a small
server.
If we think UDP-like transport is a must, we would probably have to
give up (or make optional) OCP/OPES features like encryption and
authentication. Most lossy transports have relatively small maximum
payloads that may not allow for much overhead. In fact, it would be
impossible, for example, to adapt many DNS responses because they are
already close to the maximum packet size.
To summarize, I agree that OCP over TCP (or any connection-oriented
transport) is bad for "fast occasional use" in busy environments. We
have to decide whether there is any application that requires "very
fast occasional adaptation" and that deals with busy processors and/or
services. Perhaps your "front of the resolver" is a good example, but
please clarify what you mean by that.
Thanks,
Alex.