What we'd really need is a RR type specifically intended to map
service names onto instance ID+address pairs, and also a special
query type that wasn't defined to return all of the matching RR
records, but would instead return a random subset or a subset based
on heuristics, and finally an instance ID to address mapping service.
Once again, I don't see why this would be a valid requirement.
And as I understand it, people who need this today typically host a
service behind a single address and use a load balancer to spread
incoming requests over a set of servers in such a way that the same
client returns to the same server.
yes, that's typically how it's done today, because it tends to work
better than playing games with DNS. Though part (not all) of the reason
it works better is that DNS wasn't designed to support this.
Applications need to deal with TCP connections breaking for all
sorts of reasons. Renumbering should be a relatively infrequent
event compared to all the other possible ways a TCP connection can
fail.
Mumble. Seems like the whole point of TCP was to recover from such
failures at a lower level.
TCP protects you from lots of stuff, but it doesn't really let you
recover from the remote endpoint rebooting, for example...
well, duh. if the endpoint fails then all of the application-level
state goes away. TCP can't be responsible for recovering from the loss
of higher-level state. but we're not talking about endpoint failures,
we're talking about the failure of the network. TCP is supposed to
recover from transient network failures. it wasn't designed to cope
with endpoint address changes, of course, because the network as
designed wasn't expected to fail in that way.
(And something that's common in today's IPv4 deployments: NAT
timeouts. I got bitten by that in Chicago, I think they were only a
few minutes in my hotel, drove me insane because anything other than
HTTP didn't work for long.)
given that NATs violate the most fundamental assumption behind IP (that
an address means the same thing everywhere in the network), it's hardly
surprising that they break TCP.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf