On Fri, 25 Apr 2003, jfcm wrote:
I just want to recall my "DNS support filter" (I want the final
solution to be operational to support DNS.2 - DNS new generation-
and DNS+ - exended services). They may not call on TCP and work on
UDP.
There are many OPES services which my consist of short information
being changed, upgrated, obtianed, collected, etc. that UDP could
support faster?
If my view of OPES/OCP is correct, then it makes almost no difference
whether the proxied protocol is based on TCP, UDP, or something else.
OCP is an efficient _callout_ (i.e., orthogonal to the proxied
protocol path) protocol that can use a single TCP connection to
process thousands of small application messages, with little
per-message overhead as long as the set of callout servers used by the
OPES processor is constant and of reasonable size.
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?
Alex.
P.S. We have to design OCP so that it is possible to process a
small application message with a single RTT delay (something sent
to callout server once, something received back once, no
additional exchanges on OCP level).