[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: That routing/redirection thing: mapping (?)
In this discussion I've seen five things mentioned in almost all
1. Names (members of namespaces; namespaces may have subspaces).
2. Metadata included with names (most likely via concatentation).
2.a. (Optional?) Metadata is a namespace identifier.
3. Information used to associate a request (including a name, possibly with metadata)
with a server/surrogate/etc. (metaphor: forwarding table).
4. The protocol used to convey the information used in the association is
exchanged by the entities that will perform the association.
(metaphor: routing protocol)
5. The methods used by intermediaries to cause
the requestor to issue a request in such a way that it will
reach the "correct" server/surrogate/etc. (called "redirection",
"steering", "direction", etc.)
There is a frequent assumption that the requestor must handle the
request in at least two steps: 1. resolve the name to a transport layer address
2. issues the request using transport layer addressing.
3. possibly receive an application layer command to reissue the request using
a different name; then goto step 1
In the first table, item 3 is complicated, because the association might be done
even before the request arrives (via rewriting embedded URL's). Or it might
be done by a name resolution system. Or by application layer redirection
as in the second table. That's why I think that the term "redirection" should
only be used if there is consensus about the frequent assumption above.
Even if you don't like the ponderous nature of this text, I think it may serve
to show why the documents cannot, at this point, be perfect, and why the
discussion seems to go in circles (of redirection) sometimes.
>>> Mark Nottingham <email@example.com> 11/11/00 01:31PM >>>
On Fri, Nov 10, 2000 at 10:21:03PM -0500, Markus Hofmann wrote:
> Every DIRECTION system consists of two parts:
> (a) the mapper (i.e. finding the best surrogate), and
> (b) the actual redirection mechanisms, i.e. the "client
> front end" that makes use of the mapper result and
> makes sure that the client request ends up at the
> correct surrogate.
> We can use the same mapper module with different "front ends", for
> example use the mapper module with a DNS front end or with URL
Yes. The redirection mechanism could be DNS (possibly through multiple
CNAMEs, DNS hierarchy, etc.), HTTP redirection, BGP funniness, etc. What
they base their information on is a separate matter.
Separate again is reqeust identification - associating a particular request
with metadata indended for it, such as the origin server to use (assuming
it's caching, and not replication, that's being used on the back end -- it's
really just a namespace to stick the request into, based on some aspect of
the full URI).
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)