|
From: Tod D. I. <to...@je...> - 2001-05-15 19:31:21
|
On Mon, May 14, 2001 at 09:25:00PM -0500, Michael Spencer Jr. wrote: > Forgive me for inventing or misusing terms, but... No problem, I do it all the time. :) Part of the job, you know... > I call a 'namespace' some system of naming that points you to something. A > postal address is a namespace on the set of all physical locations of > houses, businesses, etc. Ok. > In this case, I want to point out that the route to a block is a necessary > part of the namespace -- otherwise, no single node of the network knows how > to find a certain block ID on some other node of the network. So far, I can follow you, but I only partially agree. > Or to put it another way...block ID's are not sufficient to find and > download the block. You need to know where to download the block from. 1st part correct, 2nd part is assumption. > Just as we've all used the phone book to look up an address...you don't > always need every part of the namespace to find what you need. It should be > possible to use some kind of 'index service' to correlate file blocks with > the routes needed -- and it might even be possible to disclose parts of the > information to different parts of the network, so no single node or part of > the network knows everything it needs to know to map the network. Unfortunately, there aren't too may ways to index that don't break anonymity. :( > But this is a question of network design. It is of course possible to > design a network in any of several different ways: with gnutella-like > broadcast searches, with blocks-like broadcast file adverts, with central > index servers, etc. We picked one design, and we know there are several > other designs available. And I think the design you picked is a pretty good one. (It's what I would have done, with the excetpion of the modification I'm proposing). > But if you remove the routes from the file or block information > namespace...what search or broadcast service do you plan to add in its > place? What are the security, performance, or scalability factors in > whatever you add? How do they compare with the same factors in what we > already have? Here's as good a place as any to explain, I guess... I want to remove the routes and replace them with "next-hop-to" routes. example: Let us pretend that my current BLOCKS server has a route table that looks like this (for some file.zip): file.zip A H E P This means that my server can get file.zip by sending a request to server A, which sends its request to server H, which sends its request to server E, which sends its request to server P. (Am I correct? I thought this was how it worked). Now, with what I propose, my BLOCKS server would have this as a route table: file.zip A Which means that server A knows how to get to the next hop to file.zip Server A may have this: file.zip C P Which means that both servers C and P know how to get to file.zip Server C may have this: file.zip <in cache> and server P may have this: file.zip A C So server C would send the file to server A, which would send the file to my server. Server P would have a route loop, making access slow, so it would not get to participate in this transaction (probably). See what I'm trying to say? Rather than a full route, which can (in some cases) compromise anonymity, only have a "next hop" route, which doesn't. It isn't as fast, there can be (potential) problems with route loops (I say potential because by checking speed of response they shouldn't be an issue), but it should work. That is what I'd like to see. (It would also allow a server to re-advertise files in its cache to new clients, because it only has to advert that it knows how to get to the file, not that it HAS the file). > I am *not* a network design person, in this way. Most of my cool ideas > start once you already have a working network. You probably know more than > me about this anyway...but I thought my viewpoints might help structure the > discussion a bit. :) Nor am I, by any stretch of the imagination. I probably don't, I just like to play with filesharing / distributed network systems, and Blocks & Freenet are the 2 most interesting to me. (BTW: I looked at ed2k - no Linux client, no docs on how to interface w/ a server, and no working nodes. Ugh. not too impressed. Interesting idea, though). > --Spence > bl...@ms... Tod. ps. Thanks for listening. I'm probably talking out of my nether region, but thanks! -- * All opinions expressed herein belong to Me. Tod D. Ihde. So there. * * HTTP://toon.jesus-crispie.com/ HTTP://www.jesus-crispie.com/ * * The average, healthy, well-adjusted adult gets up at * * seven-thirty in the morning feeling just terrible. * * -- Jean Kerr * |