Noel Chiappa wrote:
> From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
> Regarding SRV, it's not acceptable to expect that as a condition of
> deploying a new application, every user who wishes to run that
> application be able to write to a DNS zone. Most users do not have DNS
> zones that they can write to.
Yes. Architecturally speaking, it's somewhat dubious that information which
really only needs to be localized to the host (application<->port binding)
has to be sent to the DNS.
It would be easy to run a tiny little USP "binding" server that took in an
application name (yes, we'd have to register those, but string-space is
infinite), and returned the port.
Only if it asked a well-known server ON THAT MACHINE. I.e., pick a port,
reserve it for resolution (e.g., like the RPC portmapper works).
But we cannot assume a hosts' DNS is available for that purpose. For
most of us, the DNS entry isn't under our control, nor is it likely to
be for the forseeable future.
About the only reason I can see that that would not be desirable would be to
avoid an extra RTT to the do that binding lookup. (DNS/SRV solutions might
avoid this RTT too, but in that case that benefit doesn't outweigh the
costs.) The "obvious" way to do it, which is have the ICP use the strings
directly (as the CHAOS protocols did) is not really feasible now - it would
require a change to TCP.
That could be done using a late-binding trick like we used for
string-based source routing (www.isi.edu/datarouter); we could have a
TCP option where the service name occurs (as below), and send it at
first to the 'portmapper' port, which would demux it and return it. That
does require a mod to TCP to allow the dest port to be unbound (e.g.,
'0') if the option is present, and enable the return SYN-ACK to update
the TCB on arrival.
Joe
Another option, now that I think about it, though, is a TCP option which
contained the service name - one well-known port would be the "demux port",
and which actual application you connected to would depend on the value in
the TCP option.
> Furthermore it's increasingly necessary that applications be able to
> work in environments that do not use DNS - such as ad hoc networks or
> networks that become isolated.
Also a good point.
> Probably the worst problem with destination port numbers is that there
> aren't enough of them. That's probably something that needs to be
> addressed in TCP and UDP
No, 65K is probably enough (because, recall that a single port can have
connections to hundreds of thosands of foreign ports) *provided* that we
don't have to assign a well-known port to each application.
It's the concept of well-known ports that's broken, not the provision for 65K
ports.
Noel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf