I have not worked out most of the details of my net. But please keep in mind as I said earlier my network is not really going to be anything like freenet due to its inherited limitations. I will address some of the issues I have good answers for. Others I will deal with when they come up in the design and/or implementation.
On Mon, 15 Apr 2002, Mark J Roberts wrote: > Kevin Atkinson: > > One should not have to worry about bandwidth considerations at > > all. > > Somebody has to pay for it. Yes but the bandwidth is shared and is paid for my all users of the network and not the owner of a popular site like it is with the web. > > 5) Streaming Media > > 6) Online Chat (with possible IRC or similar gateway) > > You probably won't be able to get the latency low enough without > throwing away most of your other features. Low latency is own of my design goes. And what do you mean by "other features"? > > There will not be anything like freenet's KSK keys as those proved > > to be completely insure. Instead Map keys may be requested with > > out a signature. > > That is nearly as bad: although I can't actually overwrite your > file, I can insert bogus files with similar descriptions, and the > user will have no means to discriminate between yours and mine. Yes, but they will also be ranked by popularity of the complete key (with the signature) therefore bogus keys will be near the bottom of the list. > > For efficiency reasons a node can be asked which blocks it has > > based on a given index block rather than having to ask for each > > and every data block. > > And that only helps on the off chance that the node you're > requesting from possesses the index block already? The client will already know if the node possesses the index block via the initial lookup for the key. Also, there is a high probability that if a node possesses the index block it will also possess a good number of the associated data blocks there for making this a rather useful optimization. Also, if a node contains a large number of blocks associated with an index there is a good chance it will also have the index block as the nodes will perform reverse lookups on data blocks as it receives them and if it has enough data blocks for a given index it will also retrieve the index block. > > A block size of just under 32K was chosen > > Gnunet's blocks are under 1500 bytes. They fit in an ethernet frame. > > So how are you coping with the probability of failure given so many > blocks? I not still going to use UDP for file transfers like Gnunet does. The ideas of breaking data into 32K blocks is to allow parts of files to be retrieved and for large files to be stored on multiple nodes. Each block will be requested individually and then assembled into the final file on the client size. --- http://kevin.atkinson.dhs.org _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
