Re: controversial paper
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 09/30/03
- Next message: Mok-Kong Shen: "Re: controversial paper"
- Previous message: Mxsmanic: "Re: controversial paper"
- In reply to: Mxsmanic: "Re: controversial paper"
- Next in thread: Mxsmanic: "Re: controversial paper"
- Reply: Mxsmanic: "Re: controversial paper"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 30 Sep 2003 10:54:09 +0200
Mxsmanic wrote:
>
> Mok-Kong Shen writes:
>
> > The trouble is you would have to have one central place for
> > issuing the required number in order to avoid duplicates.
>
> Not necessarily. You could have n servers, each of which serves up only
> every nth address in sequence. Periodically (daily, monthly, whatever),
> you could verify that the address space is being completely filled, and
> make any necessary adjustments. As long as requests are evenly
> distributed across the servers, the net effect would be to assign
> addresses sequentially, and yet no central control point would be
> necessary.
Even then you do have at any time a part of the address
space (namely that part that is not yet allocated) unused,
don't you (as long as one has a fixed address space of
n bits)? The (theoretical) 'efficiency' could be higher
with your allocation, but that is still a 'relative' matter
and hence the choice of the proper scheme is to be judged
together with other factors of relevance.
>
> > One needs decentralization, meaning that at each level
> > you have to have certain reserves in the address space
> > and at no time there is any consecutive part of the address
> > space that is fully (compactly) utilized (something you
> > desire, if I don't err).
>
> See above. You could assign eight servers or 128 servers, as required.
> The only constraint over time is that the address space be fully
> utilized, with no reserved but unused areas.
See my response above.
>
> > I think that the following analogy could be relevant in
> > some sense here: In programming for certain kinds of tasks,
> > one could either employ a large array that is only sparsely
> > occupied or employ a linked list that has all the entries
> > containing user data compactly stored together. Convenience,
> > if not also efficiency, considerations normally lead to the
> > employment of the first kind of data structure.
>
> Yes. Either way, you fill the address space sequentially, in time.
>
> However, if you artificially constrain the use of the address space,
> there are large portions of it that will never be filled, and at the
> same time there will be portions of it that do not have enough addresses
> available for the intended purpose.
Right. That's the 'efficiency' I referred to above. Note,
though, that in real-life one seldom (and often can't)
strive for any theoretical ideal but has to do some
compromise for economical, technical and other reasons.
Here I think that they have decided to sacrifice some
'efficiency' (in the sense mentioned above) in return
for other gains (other efficiencies), in that the scheme
selected is to be stepwise extended according to future
needs, instead of following your idea.
>
> It's important to realize that if you divided a 2^n address space into
> two fields of sizes 2^m and 2^p, you don't end up with 2^n/2 addresses,
> you end up with only about 2^m or 2^p addresses (whichever is greater).
> This is an _enormous_ reduction, no matter how you divide things up.
Theoretically you have a point, but 'practical' issues
(technical and others) may justify other ways of doing
things to be 'practically' better.
M. K. Shen
- Next message: Mok-Kong Shen: "Re: controversial paper"
- Previous message: Mxsmanic: "Re: controversial paper"
- In reply to: Mxsmanic: "Re: controversial paper"
- Next in thread: Mxsmanic: "Re: controversial paper"
- Reply: Mxsmanic: "Re: controversial paper"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
