Noel Chiappa wrote: > > From: Keith Moore <moore@xxxxxxxxxx> > > > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf