RE: [Blocks-development] V0.16 - Update

[Spencer Jr., M. <sp...@ac...>]

libblocks sounds like a great idea!  We can have our MFC-Win32 interface
(for the nontechnical or new users) after all!

Sometime down the line we should probably also code optional 'leaf node'
behavior into Blocks -- Joe Sixpack could use that to join the network and
search/download files, but not really contribute to the network.  Perhaps
non-leaf servers would have special behavior defined for 'leaf node' clients
-- 'leaf node' connections wouldn't occupy a routing letter, and would
probably just use the server they connected to as a client -- perhaps
searching its adverts.dat somehow.

But if 99% of the Blocks servers are leaf nodes, where is our safety in
numbers?  Something to think about I guess...

As far as the web-of-trust stuff, I'm going to wait for the network to
stabilize (no mixed client versions or corrupted files) before I start
playing with crypto again.

--Michael Spencer
bl...@ms...

-----Original Message-----
From: Blat Froop [mailto:pet...@ho...]
Sent: Monday, August 07, 2000 8:38 AM
To: blo...@li...
Subject: [Blocks-development] V0.16 - Update


My intention is to do the following in V0.16...

1) Protocol message to stop V0.16 interacting with previous
   versions.

2) Fix readvertisements once and for all. A number of ads will
   be sent when there are new connections, and a larger number
   will be sent slowly by crawling through the list over the
   next 12 hours or so. Readvertisements will never be routed
   or forwarded.

3) Persistent 'sticky' file upload will be added. Content will
   never be deleted until the cache is destroyed (server restart
   etc). The blocks for these will exist in the cache, but
   will not form any part of the cache allocation space. Initially,
   there will be no explicit delete functionality. (Perhaps
   load/save functionality for upload list? Also, if I do away
   with the upload progress bar and do something similar to what
   happens with download this would allow background uploading
   while you do other stuff... is this desirable?).

4) Smarter routing logic. Try and not cache files which are
   larger than 10% of the available cache. This means that
   big files will only get cached on big servers.

5) Lots of tweaks & fixes.

Possible things to think about for future versions...

* Scramble routing letter A-P, or at least allocation order.
* Web Of Trust
* Moving logic from blockgui into libblocks to allow
  access to blockd (comand line or HTTP, etc), at the
  moment blockd just forwards and forgets ads.
* What are we going to do about large > 250Mb files?
* Flooding, and script kiddies.

Comments? Additions? Did I miss anything?

ttfn

PG.


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development