blocks-development — Main mailing list for Blocks

Re: [Blocks-development] Resuming

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: [Blocks-development] Resuming
>Date: Mon, 14 Aug 2000 04:32:50 +0200
>
>If a download fails and I restart it later, shouldn't Blocks check if
>blocks of the to-be-downloaded files are already in the local cache?
>That way, we could have resuming -- the first blocks would be fetched
>from the local cache, and the rest from the remote host.
>
>Of course, I presume that the blocks of failed downloads are stored
>in the cache.

They are stored, and Blocks should use them when you restart the
download. All Blocks servers always check the local cache before
routing requests, however, looking at the code it seems they only
do this when proxying/routing requests and not when they are
the source of the request themselves. Looks like a bug to me :-)

ttfn

PG.

PS big file support soon :)
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] Resuming

[Erik M. <mo...@sc...>]

If a download fails and I restart it later, shouldn't Blocks check if 
blocks of the to-be-downloaded files are already in the local cache? 
That way, we could have resuming -- the first blocks would be fetched 
from the local cache, and the rest from the remote host.

Of course, I presume that the blocks of failed downloads are stored 
in the cache.

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

Re: [Blocks-development] Future Direction For Blocks

[Erik M. <mo...@sc...>]

On 12 Aug 2000, at 18:30, Blat Froop wrote:

> Its beena bit quiet on the list recently

We're all eagerly waiting for the next release, considering the great 
features it will bring us ;-). I'm especially interested in sticky 
file support so that I can quickly start up a Blocks node with lots 
of files.

> V0.16 will still be released in a week or so, but the only
> significant changes will really be the addition of 'sticky'
> files

Yay!
 
> In the meantime I was thinking about the future direction
> of Blocks. There has been a lot of discussion around Michaels
> Web-Of-Trust idea, but so far there is no real substance
> availale for general discussion.

Before we go to ratings and authentication, we should clear the 
scalability issue and possible routing/resuming problems. We might 
want to do a little (!) bit of promotion to get a few more testers in.

> So, what do we want to do with Blocks?
> 
> Heres a few ideas off the top of my head...
> 
> 1) Allow (optional) HTTP access to servers, with search and
>    download ability. Perhaps upload as well. This would allow
>    modemers and people without always on inet connections
>    access to content on the Blocknet. If this were commonplace
>    perhaps the Blocknet would simply become a fancy backbone
>    to this larger systems supporting thousands of low bandwidth
>    users?

Interesting. There needs to be strict bandwidth regulation, though -- 
deny new connections if bandwidth is full.

> 2) Aim at giving good support for *huge* files. Currently
>    Blocks is inefficient for files < ~150Kb anyway, but there
>    seems to be a lack of file sharing utilities that are
>    particularly suitable for large files (video, CD images, etc). This
>    would require Blocks servers to have even larger chaches (at least
>    4+ Gb), and probably mean that files may have to be split across
>    more than one server... creating an informal mixnet. It might be
>    possible to simply split the large files into smaller ones and make
>    Blocks simply join them back up on download.

Can't we just use additional header blocks if necessary?

> 3) Add a rating/voting system. It could be possibly to broadcast
>    'issues' to vote on, and also allow people to broadcast 'votes' on
>    these issues and also on files as well. Now, because of the dynamic
>    nature of the Blocknet all the servers would have slightly
>    different results, but perhaps this woudlnt really matter.

Yes, ratings are very important, as I will continue to emphasize ;). 
Before we implement them, however, I suggest we create a way for each 
individual Blocks user to create an "identity" (i.e. nickname, 
public+private key). This could be attached to file adverts. Later, 
we can change the scope of adverts to include ratings, votes etc.

> 4) Add TCP/IP socket routing via the Blocknet. This would allow
>    IP anonymous surfing, irc, telnet, etc. 

Before we do this, we need some cleverer bandwidth regulation 
mechanisms, also WRT the scalability in a highly mixed connection 
speed network. I will write more on this as soon as I can get some 
work on the simulation done (I plan to do this before I go on 
vacation on August 25.)

Last but not least, no need to hurry. We're on no deadline and we 
want to get this thing done right. Of course, if you got too many 
unoccupied brain cells, you can help me with the simulator ;->.

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

[Blocks-development] Future Direction For Blocks

[Blat F. <pet...@ho...>]

Its beena bit quiet on the list recently, and that cant be
such a bad thing given the number of changes which were
released recently. V0.15.1 seems to be holding up remarkably
well, and the new uploading and readvertisement logic doesnt
seem to have any serious problems.

Its probably worth discontinuing V0.14 support, so I would
suggest Luke upgrades his server to V0.15.1 (and changes the
port number) in preperation for V0.16

V0.16 will still be released in a week or so, but the only
significant changes will really be the addition of 'sticky'
files, and upgraded Makefiles so that Linux builds cleanly
without alteration of any files.

In the meantime I was thinking about the future direction
of Blocks. There has been a lot of discussion around Michaels
Web-Of-Trust idea, but so far there is no real substance
availale for general discussion. The simulator is a good
idea for proving that Blocknets are scalable, but is a
(important) side issue to where we are actually going with
all this.

So, what do we want to do with Blocks?

Heres a few ideas off the top of my head...

1) Allow (optional) HTTP access to servers, with search and
   download ability. Perhaps upload as well. This would allow
   modemers and people without always on inet connections
   access to content on the Blocknet. If this were commonplace
   perhaps the Blocknet would simply become a fancy backbone
   to this larger systems supporting thousands of low bandwidth
   users?

2) Aim at giving good support for *huge* files. Currently
   Blocks is inefficient for files < ~150Kb anyway, but there
   seems to be a lack of file sharing utilities that are
   particularly suitable for large files (video, CD images, etc).
   This would require Blocks servers to have even larger chaches
   (at least 4+ Gb), and probably mean that files may have to
   be split across more than one server... creating an informal
   mixnet. It might be possible to simply split the large
   files into smaller ones and make Blocks simply join them
   back up on download.

3) Add a rating/voting system. It could be possibly to broadcast
   'issues' to vote on, and also allow people to broadcast 'votes'
   on these issues and also on files as well. Now, because of
   the dynamic nature of the Blocknet all the servers would have
   slightly different results, but perhaps this woudlnt really
   matter. Flooding/Spamming would seem a real issue here, but
   is it really that much worse than the general case?

4) Add TCP/IP socket routing via the Blocknet. This would allow
   IP anonymous surfing, irc, telnet, etc. This would require
   Blocks to use a smaller data block size and therefore
   multiple header blocks etc, so that delays were minimised
   for near realtime applications. This would be difficult, but
   not impossible.

Just a few ideas to get us all thinking. Please feel free to
comment or suggest new ideas. Its brainstorming time, so even daft
ideas are fine :-)

ttfn

PG.

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

Re: [Blocks-development] HOWTO: building Blocks on Linux

[Blat F. <pet...@ho...>]

You might also want to mention to include -L/usr/X11R6/lib in
the LIB= line in the Makefile as well.

I just a number of bugetts in the UNIX code for the new upload
window while hacking V0.16. This has got to effect Linux users
using the V0.15 blockgui?? Nobody has complained about this so far.
Downloading should work OK. Perhaps we should place a warning on
the web page. V0.15 blockd should be ok.

V0.16 will now be released a few days earlier than expected
(probably early next week) and will contain less new features
then expected, but will fix the Linux build problems, and the
general UNIX upload problems.

Ho hum,

PG.



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

[Blocks-development] HOWTO: building Blocks on Linux

[Blat F. <pet...@ho...>]

Ok, heres the latest news, can we put this up on the web page
somewhere?

Blocks V0.15 can be built on Linux by doing the following...

1) edit the following files...

   blocks/blockd/Makefile
   blocks/blockgui/Makefile

and change the line which says...

LINKEXE=$(CC) -o $(TARGET) $(OBJ) $(LIB)

to read...

LINKEXE=$(CXX) -o $(TARGET) $(OBJ) $(LIB)

and also remove the "-lnsl -lsocket" from the LIB= line.

2) vi blocks/libsock/sock.cpp

   change "sigignore(SIGPIPE);" to say "signal(SIGPIPE,SIG_IGN);"

(NOTE: this step may not be necessary)

3) in the 'blocks' directory do the following...

make clean; make depend; make

(NOTE: you need 'makedepend' pathed its usually in
       /usr/X11R6/bin or /usr/openwin/bin)

and the resulting binaries should be blocks/blockgui/blockgui
and blocks/blockd/blockd

ttfn

PG.

PS V0.16 will work out of the box as the new Makefiles
   autodetect Solaris and default to Linux.




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

Re: [Blocks-development] Linux build errors...

[Benjamin M. B. <br...@kr...>]

Pete,
I'll try it this evening. I made the linux blockd but I forgot to post
it. I'll do that this evening as well. Sorry :)

On Tue, 8 Aug 2000, Blat Froop wrote:

> I have reports that blockgui has build errors
> under Linux...
> 
> gcc -o blockgui    blockgui.o entropy.o mainwin.o progress.o searchwin.o
> uploadwin.o -L/usr/X11R6/lib ../libblocks/libblocks.a ../libsock/libsock.a
> ../../fltk/lib/libfltk.a -lX11 -lm
> entropy.o: In function `EntropyWin::EntropyWin(void)':
> /usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:14: undefined reference to
> `__throw'
> /usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:17: undefined reference to
> `__throw'
> /usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:20: undefined reference to
> `__throw'
> /usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:23: undefined reference to
> `__throw'
> /usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:26: undefined reference to
> `__throw'
> ...
> 
> Now, this looks to me to be a simple linking error due to
> gcc being used for the final link rather than g++.
> 
> Now, if Im right you should just have to change the Makefile
> line which says...
> 
> LINKEXE=$(CC) -o $(TARGET) $(OBJ) $(LIB)
> 
> to read...
> 
> LINKEXE=$(CXX) -o $(TARGET) $(OBJ) $(LIB)
> 
> and the problem should go away.
> 
> Can someone on the mailing list try this out?
> I dont have any direct access to Linux.
> 
> 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
> 

[Blocks-development] Linux build errors...

[Blat F. <pet...@ho...>]

I have reports that blockgui has build errors
under Linux...

gcc -o blockgui    blockgui.o entropy.o mainwin.o progress.o searchwin.o
uploadwin.o -L/usr/X11R6/lib ../libblocks/libblocks.a ../libsock/libsock.a
../../fltk/lib/libfltk.a -lX11 -lm
entropy.o: In function `EntropyWin::EntropyWin(void)':
/usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:14: undefined reference to
`__throw'
/usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:17: undefined reference to
`__throw'
/usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:20: undefined reference to
`__throw'
/usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:23: undefined reference to
`__throw'
/usr/local/aoetmp/src/blocks/blockgui/entropy.cxx:26: undefined reference to
`__throw'
...

Now, this looks to me to be a simple linking error due to
gcc being used for the final link rather than g++.

Now, if Im right you should just have to change the Makefile
line which says...

LINKEXE=$(CC) -o $(TARGET) $(OBJ) $(LIB)

to read...

LINKEXE=$(CXX) -o $(TARGET) $(OBJ) $(LIB)

and the problem should go away.

Can someone on the mailing list try this out?
I dont have any direct access to Linux.

ttfn

PG.


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

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

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: Re: [Blocks-development] V0.16 - Update
>Date: Mon, 7 Aug 2000 19:53:34 +0200
>
>On 7 Aug 2000, at 13:38, Blat Froop wrote:
>
> > 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.
>
>But when the server readvertises its own adverts, this also includes
>readvertisements it has received, I suppose? That would make sense to
>me (no duplicate ads, of course, only if it has only received the re-
>ad, not the original one).

Readvertisements are only sent after new connections are made/received... 
sending them at any other time wouldnt be
practical since the immediately adjacent server would simply
trash them as duplicates anyway. I suppose I could add logic
to recrawl though the list every couple of days, but it is
likely to simply increase bandwidth without much benefit.

One problem I have is that the new server will probably
get lost of duplicate adverts during when its connected
to by other servers, since the servers send the most
recent ads are sent by all concerned, and they're probably
all going to be the same. So how do we make this more efficient?

ttfn

PG.



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

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

[Erik M. <mo...@sc...>]

On 7 Aug 2000, at 13:38, Blat Froop wrote:

> 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.

But when the server readvertises its own adverts, this also includes 
readvertisements it has received, I suppose? That would make sense to 
me (no duplicate ads, of course, only if it has only received the re-
ad, not the original one).

More later,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

RE: [Blocks-development] Sim Blocks

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

My thoughts on a simulator:

BLOCKS IS TWO LAYERS

currently Blocks is a two-layer system:  network and protocol.  (I'm trying
to borrow from OSI names here, and I may have picked the wrong ones.  My
names are not set in stone.)  The network layer manages client connections,
routes file ads, new-connection ads, and blocks.  (Right?)  The protocol
layer does intelligent things with the network-layer data:  figures out what
to do with file adverts, when to create new ones...and knows when to send
and receive blocks and what to do with the data (reconstruct a file, etc.)

(Just because it's my pet project, I will add:  the web-of-trust, when it's
finally implemented, would be another couple layers on top of that.)

SIMULATE THE LAYERS SEPARATELY

I think we can simplify the problem if we analyze and harden the two layers
independently -- both layers are necessary for the whole to operate, and
either layer can fail without the presence of a design flaw in the other
layer.  If the network layer is weak but the protocol layer is strong, then
we'll find we have a problem establishing and maintaining connections...but
what few connections we can keep up route files very effectively.
Conversely, if the network layer is strong but the protocol layer is weak,
then we'll be able to communicate packets very effectively but we'll have
problems helping content producers and content consumers find each other.

NETWORK THREAT MODEL

I think this one is the biggie:  will the network scale as you add more
permanent hosts, temporary/transient hosts, and malicious hosts...and how
many of the last two does it take to break the network?

The successful attacks against the network will probably be things we've
never thought of...but offhand I can think of floods, constantly connecting
and disconnecting from hosts, putting a low-bandwidth server in a central
'hub' location...

NETWORK SIMULATOR

To simulate a large network I believe this can best be done as a collection
of nodes, where each node is a fixed-length structure...and the structures
can be stacked neatly in a flat file.  You'd probably need separate files
and data structures for the network traffic...but the turn-based flow would
probably go: in-queue, process, out-queue, delivery.

This is a programming task probably beyond my ability, but I'll be glad to
spec out a big complicated mess and make a ton of work for somebody else.

I suppose you would need to make a list of client-types, where each client
would have 'program behavior' and 'user behavior'.  Most of the network (80%
at least, I hope) would consist of a few thousand long-term
standard-behavior clients.  Then we would custom-code other client types:  a
fickle temporary/transient host, and whatever malicious host types we could
dream up.

The simulation would run through the node list file once per turn...and I
suppose the file could be closed after every turn, so an external program
could map and analyze the structure of the network.

I don't know most of this stuff -- my mind feels all swimmy.  Isn't there a
branch of mathemetics that prepares you for this stuff?

PROTOCOL THREAT MODEL

OK, assuming we have a working network, how can someone abuse the protocol?
We'd have to define the protocol's goals, and how we can measure whether or
not the protocol is being successful.

I suppose a successful protocol lets people publish information widely, and
lets people find and retrieve published information easily.

How do you abuse the protocol?  You can obviously spam the network with
false file adverts...but how do you differentiate between someone flooding
with bogus file adverts...someone sharing and broadcasting tens of thousands
of adverts for little 10 K text files...and someone sharing and broadcasting
tens of thousands of adverts for little 10 K text files with actual useful
information in there somewhere.

You could consider me personally to be an attacker against the protocol:  if
you don't believe in this web of trust stuff, and suddenly one day you
search for * and find 50 or so interesting files, and 150 or so 70-letter
filenames saying pk- and cs- and ks- and a few dozen random hex
digits...then you could probably accuse me of spamming everyone's file
adverts.

So this needs to be carefully defined, probably by someone else.  :)

PROTOCOL SIMULATION

I have no earthly idea how to do this.  :)  Can someone else step forward?

IMPLEMENTATION

Java would be nice...an interpreted run-time language for custom coding of
malicious client behavior would also be nice...but maybe not practical.
Perhaps after we build the client, we should have a coder in one hand and an
ideas person in the other, and they work together to do tests?

Again...I don't know how to do this, because I'm not that good a coder...but
I'll be glad to dream up crazy ideas and make work for someone else.  :)

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


-----Original Message-----
From: Erik Moeller [mailto:mo...@sc...]
Sent: Saturday, August 05, 2000 2:14 PM
To: blo...@li...
Subject: [Blocks-development] Sim Blocks


It would be very useful to have a simulator for testing the 
scalability and vulnerability of BlockNets. I talked already with 
Michael about this. We could simulate various changes to the protocol 
without actually implementing them, simply by adding or changing a 
few numbers here and there. We could also do very-large-scale tests 
with 100,000 nodes and more. Basically, if we don't do this it's a 
"fire & forget" strategy -- we don't really know the outcome.

So a simulator would be excellent and if we intend this program to be 
more than a short proof-of-concept, it would be very useful for the 
further development. It's obvious that Peter can at best look over 
it, since he's far too busy to implement it. So anyone who can 
"speak" Java and is willing to contribute to this should speak up.

- - -

Here's a more detailed proposal:

	- turn based simulation
	- everything that's unique (adverts, files etc.)
	  should also have unique representations in the
	  simulation
	- Java, AWT GUI (for visual representation:
	  canvas with 1 pixel per node, 1 pixel between
	  each, lines between pixels visualize file
	  transfers / routes)
	- Reason for Java: cross-platform, easy to use

	Required data:

	global:
	- number of good nodes 
	- readvertising frequency
	- individual advert size
	- optional: number of bad nodes
	   - flooders
	   - DoSers (don't use Blocks, but 
 	     attack a certain IP-can't be
         locked out, might focus on
	     prominent nodes)
	   - fakers
	   - filters
	   - analyzers / hoppers
	   - ?

	individual:
	for these numbers we need a distribution table,
	e.g.: 56 kbps; 5%; 64 kbps: 10% ..
    or randomly picked from a range:
	      0-4h:10%; 4-12h:25%
	- speed of nodes
	- uptime
	- number of local files 
	- file requests / hour
	- cache size
	- non-ad-routing: how many % don't route ads?
	- "prominence":
	  how well the nodes are known, e.g.
	  50-100% know this node:1%
      30-50% know this node:4%
	  10-30% know this node:10%
	  0-10% know this node:85%
	  (when a node reconnects, the prominent
	  connection points are connected to more
	  often).
	- cancel frequency: when and how likely 
	  will the user cancel the download?
 	  when=at which speed threshold, e.g.
	  at <50% of maximum speed: 1%
	  at 40-50% of max speed: 3%
	  ..
	  at 5-10% of max speed: 40%
	  at 0-5% of max speed: 60%
	- ?

	Optional:
	frustration - after a certain number of cancels
	 and failed downloads, the user is frustrated 
     and quits the network. A threshold for this 
	 could be defined.

	Implementation:
	The nodes are generated as a vector of objects.
	In a loop, each nodes can generate several	
	actions (request, upload, disconnect, continue
	downloading of a requested file, cancel, send
	advert, send file etc.), actions that regard 
	other nodes are put in their event queue which
    is processed as soon as possible, according to
	the bandwidth that the node can use per turn.

	Afer one loop is complete, a number of new nodes
	is generated randomly and added to the vector.
	
	The display is updated. Repeat on user request 
	(step by step) or automatically.

	Gatherable data:

	How many nodes d/l at x % of their max speed?
	How many d/ls fail?
	What is the average bandwidth required by adverts?
	How is it distributed?
	Which regions of the network are congested and how
	could this be alleviated?
	How many evil nodes can we tolerate?
	etc.

Comments welcome.

Regards,
Erik

PS: Yes, these proposals will eventually be put on the web as soon as 
I have an FTP account.
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

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

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

[Blocks-development] V0.16 - Update

[Blat F. <pet...@ho...>]

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

Re: [Blocks-development] [Blocks] upload problem

[Blat F. <pet...@ho...>]

>From: Michael Ray <sh...@in...>
>To: blo...@li...
>Subject: [Blocks-development] [Blocks] upload problem
>Date: Sat, 05 Aug 2000 19:33:55 -0700
>
>So far I have only had one repeatable consistent problem. I have one file
>that will not upload.  At a bit under 540 meg, I suspect that size is the
>problem.  Every time it dies before it can finish constructing the blocks.
>

Blocks currently has a dumb ~250Mb limit on file sizes. This is
because it only allows a single 64Kb header block, which only
has space for 4087 data block IDs. Each 64K data block is actually
contains 65392 bytes of data, so the largest file you can upload
is 4087*65392 => 267257104 bytes => ~254Mb. Perhaps this should
be on the web page somewhere?

Once we've sorted out the network building and file advertisement
logic in Blocks I intend to look at this problem, especially
since Blocks would appear to be much more suitable for very
large files than some of its competitors (if it really has any :)

One possible solution is to allow the chaining of header blocks,
so that the file can be any size upto ~2Gb, but files > 1Gb run
the risk of trashing all the caches they pass through due to
their enormous size, so perhaps the caching logic would have to
be upgraded as well? Its definately a problem for later on though.

>BTW, I love the new upload interface.

Cool, its a pity FLTK doesnt have double-click events in
FLTK Browser widgets, but other than that Im pretty happy with
it so far :)

ttfn

PG.

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

[Blocks-development] Sim Blocks

[Erik M. <mo...@sc...>]

It would be very useful to have a simulator for testing the 
scalability and vulnerability of BlockNets. I talked already with 
Michael about this. We could simulate various changes to the protocol 
without actually implementing them, simply by adding or changing a 
few numbers here and there. We could also do very-large-scale tests 
with 100,000 nodes and more. Basically, if we don't do this it's a 
"fire & forget" strategy -- we don't really know the outcome.

So a simulator would be excellent and if we intend this program to be 
more than a short proof-of-concept, it would be very useful for the 
further development. It's obvious that Peter can at best look over 
it, since he's far too busy to implement it. So anyone who can 
"speak" Java and is willing to contribute to this should speak up.

- - -

Here's a more detailed proposal:

	- turn based simulation
	- everything that's unique (adverts, files etc.)
	  should also have unique representations in the
	  simulation
	- Java, AWT GUI (for visual representation:
	  canvas with 1 pixel per node, 1 pixel between
	  each, lines between pixels visualize file
	  transfers / routes)
	- Reason for Java: cross-platform, easy to use

	Required data:

	global:
	- number of good nodes 
	- readvertising frequency
	- individual advert size
	- optional: number of bad nodes
	   - flooders
	   - DoSers (don't use Blocks, but 
 	     attack a certain IP-can't be
         locked out, might focus on
	     prominent nodes)
	   - fakers
	   - filters
	   - analyzers / hoppers
	   - ?

	individual:
	for these numbers we need a distribution table,
	e.g.: 56 kbps; 5%; 64 kbps: 10% ..
    or randomly picked from a range:
	      0-4h:10%; 4-12h:25%
	- speed of nodes
	- uptime
	- number of local files 
	- file requests / hour
	- cache size
	- non-ad-routing: how many % don't route ads?
	- "prominence":
	  how well the nodes are known, e.g.
	  50-100% know this node:1%
      30-50% know this node:4%
	  10-30% know this node:10%
	  0-10% know this node:85%
	  (when a node reconnects, the prominent
	  connection points are connected to more
	  often).
	- cancel frequency: when and how likely 
	  will the user cancel the download?
 	  when=at which speed threshold, e.g.
	  at <50% of maximum speed: 1%
	  at 40-50% of max speed: 3%
	  ..
	  at 5-10% of max speed: 40%
	  at 0-5% of max speed: 60%
	- ?

	Optional:
	frustration - after a certain number of cancels
	 and failed downloads, the user is frustrated 
     and quits the network. A threshold for this 
	 could be defined.

	Implementation:
	The nodes are generated as a vector of objects.
	In a loop, each nodes can generate several	
	actions (request, upload, disconnect, continue
	downloading of a requested file, cancel, send
	advert, send file etc.), actions that regard 
	other nodes are put in their event queue which
    is processed as soon as possible, according to
	the bandwidth that the node can use per turn.

	Afer one loop is complete, a number of new nodes
	is generated randomly and added to the vector.
	
	The display is updated. Repeat on user request 
	(step by step) or automatically.

	Gatherable data:

	How many nodes d/l at x % of their max speed?
	How many d/ls fail?
	What is the average bandwidth required by adverts?
	How is it distributed?
	Which regions of the network are congested and how
	could this be alleviated?
	How many evil nodes can we tolerate?
	etc.

Comments welcome.

Regards,
Erik

PS: Yes, these proposals will eventually be put on the web as soon as 
I have an FTP account.
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

[Blocks-development] [Blocks] upload problem

[Michael R. <sh...@in...>]

So far I have only had one repeatable consistent problem. I have one file 
that will not upload.  At a bit under 540 meg, I suspect that size is the 
problem.  Every time it dies before it can finish constructing the blocks.

Understand, that is not a complaint, but a bug report :)

BTW, I love the new upload interface.  

[Blocks-development] suggestions - readvertisements

[Blat F. <pet...@ho...>]

>From: "Michael Spencer Jr." <bl...@ms...>
>To: "Erik Moeller" <mo...@sc...>,        
><blo...@li...>
>Subject: Re: [Blocks-development] Some suggestions
>Date: Sat, 5 Aug 2000 10:26:39 -0500
>
>I agree about mixing up the routing letters.  This sounds like a good idea.
>:)
>
>But remember that a lot of those 'inconvenient' features are very good for
>security -- file advert flooding (through too much traffic) becomes less of
>a problem if we don't rebroadcast file adverts so much.  Remember that this
>client that just connected to you might already have four other connections
>when you send your file list to him.

Yup, in V0.15, initial readvertisements are not forwarded. They
are just used to build an initial adverts.dat file. Im still
thinking about wether the slow readvertisement of files over
time should just be the same as initial adverts, similar to
readvertisements, or some new message type with slightly
different behaviour.

If they were just the same as initial readvertisements they
would slowly migrate from server to server over a long time,
but this would depend on how quickly we crawl through the
list. Say we readvertise one file every 30secs to each
connection (remember there are up to 16 connections so
this implies one ad every ~2 secs!)... then it would take
100000/2 = 50000 secs = ~14 hours to resend the whole
advert list. Which doesnt sound unreasonable.

>
>Leaving it as a user-configurable option is probably the best bet.  
>However,
>maybe sometime down the road the client program should keep track of which
>routes it's advertised to which connections, and not readvertise those
>routes.

This is slightly complicated by the fact that we're dealing
with a pretty big list (at the moment 100000) of adverts, but
thinking about it, if we only needed a single bit to store
a flag, we would only need 16*100000/8 = ~256Kb of memory for
this feature. Thats definately a real possibility.

I think this might even be a V0.16 feature! :)

>Also, if malicious clients become a problem someday, perhaps the
>client should automatically attempt to retrieve the header and some random
>blocks from a random subset of file adverts received over a link, to 
>confirm
>that the files being advertised exist...and drop the connection (and take
>other measures perhaps) if many or most of the files are bogus.


Im not sure that would scale well, the majority of the adverts
would be multiple hops away. prefer popular content be be
replicated.

Keep the suggestions and comments coming :)

ttfn

PG.

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

Re: [Blocks-development] Some suggestions

[Michael S. Jr. <bl...@ms...>]

I agree about mixing up the routing letters.  This sounds like a good idea.
:)

But remember that a lot of those 'inconvenient' features are very good for
security -- file advert flooding (through too much traffic) becomes less of
a problem if we don't rebroadcast file adverts so much.  Remember that this
client that just connected to you might already have four other connections
when you send your file list to him.

Leaving it as a user-configurable option is probably the best bet.  However,
maybe sometime down the road the client program should keep track of which
routes it's advertised to which connections, and not readvertise those
routes.  Also, if malicious clients become a problem someday, perhaps the
client should automatically attempt to retrieve the header and some random
blocks from a random subset of file adverts received over a link, to confirm
that the files being advertised exist...and drop the connection (and take
other measures perhaps) if many or most of the files are bogus.

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


----- Original Message -----
From: "Erik Moeller" <mo...@sc...>
To: <blo...@li...>
Sent: Saturday, August 05, 2000 9:25 AM
Subject: [Blocks-development] Some suggestions


> Just a few suggestions for the coming versions after the patch.
>
> - Should the letters assigned to the IP numbers be randomly
>   picked instead of the order of their apperance? Right now,
>   the primary server is always "A". If the primary server
>   is very common (like it is right now) it is possible to
>   guess that a certain IP number reappears in the path, e.g.
>   CADDAF probably means that one of our two primaries is at
>   hop 2 and 5. I suppose encryption as suggested in the protocol
>       specs would also solve this problem.
> - adverts for the same file with different routes could be
>   summarized
> - initial handshaking should contain a version number and
>   optionally a "network name", which is sort of a password
>   that can be used to isolate networks easily. Of course,
>   this should be encrypted like everything else.
> - improved cache flushing:
>   Flushing all local files seems pretty pointless since at
>   least some of them are probably stored permanently
>   somewhere else. This is especially annoying for users
>   whose connections are cut every 24 hours, or those who
>   cannot let their PC run all day.
>
>       The solution I suggest is pretty tricky, but I think it should
>   be implemented before we go to a larger public. I suggest
>   to have two options for uploading files: "temporary upload"
>   and "persistent upload". Persistently uploaded files would be
>   stored in a separate cache that is encrypted with a permanent
>   cipher and only flushed on explicit request.
>
>   That way, you could upload your MP3 collection once and you
>   would never have to think again about it. One other advantage
>   is that the hash of the files remains the same so that there
>   are not lots of different adverts for the same files floating
>   around. Security of the other non-local files would not be
>   affected.
> - optional expiry date for adverts. The TTL limits them in space,
>   the expiry date would limit them in time. This is important for
>   files like messages, which are only relevant for a week or so
>   and should then stop circulating on the network. I don't know
>   how hard this is to do since the adverts would have to be
>   updated regularly.
>
> Regards,
> Erik Moeller
> --
> Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
> Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
> The Origins of Peace and Violence: <http://www.violence.de>
> Please donate free food NOW: <http://www.thehungersite.com>
>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development

Re: [Blocks-development] Some suggestions

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: [Blocks-development] Some suggestions
>Date: Sat, 5 Aug 2000 16:25:12 +0200
>
>Just a few suggestions for the coming versions after the patch.
>
>	- Should the letters assigned to the IP numbers be randomly
>	  picked instead of the order of their apperance? Right now,
>	  the primary server is always "A". If the primary server
>	  is very common (like it is right now) it is possible to
>	  guess that a certain IP number reappears in the path, e.g.
>	  CADDAF probably means that one of our two primaries is at
>	  hop 2 and 5. I suppose encryption as suggested in the protocol
>       specs would also solve this problem.

Yes, but there is a problem with the encrypted solution when
clients disconnect since the 'bad route' logic doesnt know which
routes are bad since they are encrypted and all look different.
Choosing a non-linear A-P set which was static for the server
(or perhaps mixed with entropy from the content_hash) might make
things more difficult, but the thinking hat is still on for this
one.

>	- adverts for the same file with different routes could be
>	  summarized

At the moment the searching logic is pretty dumb... go bad through
the advert file until we have enough matches. More complex logic
could be added to make it more useable. This will probably happen
eventually tho its a low priority.

>	- initial handshaking should contain a version number and
>	  optionally a "network name", which is sort of a password
>	  that can be used to isolate networks easily. Of course,
>	  this should be encrypted like everything else.

Looks like this is needed, at least to stop different versions interacting 
badly. Not sure about "network names" tho.

>	- improved cache flushing:
>	  Flushing all local files seems pretty pointless since at
>	  least some of them are probably stored permanently
>	  somewhere else. This is especially annoying for users
>	  whose connections are cut every 24 hours, or those who
>	  cannot let their PC run all day.

Blocks really does need long term connections rather than
connections which are continously broken. If Blocks has
a network as unstable as GNUtella's we'd all get flooded with
connetion and bad route messages continiously.

Another possibility is that a seperate Blocks 'client' could
be created, targetted at low bandwidth, and unstable, connections.
This would connect to the server network, and be able to
search (not broadcast, but server does the searching), download,
possibly upload, and disconnect.

>
>       The solution I suggest is pretty tricky, but I think it should
>	  be implemented before we go to a larger public. I suggest
>	  to have two options for uploading files: "temporary upload"
>	  and "persistent upload". Persistently uploaded files would be
>	  stored in a separate cache that is encrypted with a permanent
>	  cipher and only flushed on explicit request.
>
>	  That way, you could upload your MP3 collection once and you
>	  would never have to think again about it. One other advantage
>	  is that the hash of the files remains the same so that there
>	  are not lots of different adverts for the same files floating
>	  around. Security of the other non-local files would not be
>	  affected.
>	- optional expiry date for adverts. The TTL limits them in space,
>	  the expiry date would limit them in time. This is important for
>	  files like messages, which are only relevant for a week or so
>	  and should then stop circulating on the network. I don't know
>	  how hard this is to do since the adverts would have to be
>	  updated regularly.

I think 'sticky' files will definately make it into Blocks sometime
soon. An expiry date is an interesting idea.

Perhaps we should have an 'Ideas for discussion' or 'Future Proposals'
section on the web page?

ttfn

PG.
ttfn

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

[Blocks-development] Some suggestions

[Erik M. <mo...@sc...>]

Just a few suggestions for the coming versions after the patch.

	- Should the letters assigned to the IP numbers be randomly
	  picked instead of the order of their apperance? Right now,
	  the primary server is always "A". If the primary server
	  is very common (like it is right now) it is possible to
	  guess that a certain IP number reappears in the path, e.g.
	  CADDAF probably means that one of our two primaries is at
	  hop 2 and 5. I suppose encryption as suggested in the protocol
      specs would also solve this problem.
	- adverts for the same file with different routes could be 
	  summarized
	- initial handshaking should contain a version number and 
	  optionally a "network name", which is sort of a password
	  that can be used to isolate networks easily. Of course,
	  this should be encrypted like everything else.
	- improved cache flushing:
	  Flushing all local files seems pretty pointless since at
	  least some of them are probably stored permanently
	  somewhere else. This is especially annoying for users
	  whose connections are cut every 24 hours, or those who
	  cannot let their PC run all day.
	 
      The solution I suggest is pretty tricky, but I think it should
	  be implemented before we go to a larger public. I suggest
	  to have two options for uploading files: "temporary upload"
	  and "persistent upload". Persistently uploaded files would be
	  stored in a separate cache that is encrypted with a permanent
	  cipher and only flushed on explicit request.

	  That way, you could upload your MP3 collection once and you
	  would never have to think again about it. One other advantage
	  is that the hash of the files remains the same so that there
	  are not lots of different adverts for the same files floating
	  around. Security of the other non-local files would not be
	  affected.
	- optional expiry date for adverts. The TTL limits them in space,
	  the expiry date would limit them in time. This is important for
	  files like messages, which are only relevant for a week or so	
	  and should then stop circulating on the network. I don't know
	  how hard this is to do since the adverts would have to be
	  updated regularly.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

[Blocks-development] Important - V0.15

[Blat F. <pet...@ho...>]

Well,

V0.15 seems to work quite well, but it doesnt interoperate well
with V0.14. In particular, files listed in the search window
with a blank HASH field will fail to download (they are being
sourced by a V0.14 server) with the error "incorrect header ID".

Also, Erik has afound a buffer overrun bug which causes
corruption when uploading files with names > 86 characters.

So, dont point a V0.15 server at the public test servers right
now. We'll patch V0.15 and relaunch tomorrow (Saturday) with a new
master server location (port change) so that we are completely
seperate from the V0.14 network which will be left to die
naturally.

ttfn

PG.


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

Re: [Blocks-development] V0.15 is here!

[Benjamin M. B. <br...@kr...>]

If Erik gets the page done this evening, I'd like him to send it to me,
and I'll stick it online. I'll also work on the Linux binaries later this
evening, as I unfortunatley don't have access to a linux box at work.

-Ben

On Fri, 4 Aug 2000, Blat Froop wrote:

> Well, V0.15 is ready and the following changes have been implemented...
> 
> 1) All whole now multiple uploads capability for
>    bulk uploading.
> 
> 3) Add content hash to adverts and header blocks,
>    and display this in the serach window.
> 
> 2) Fix timeouts and problems when uploading &
>    downloading at the same time.
> 
> 4) Increase the smartness of the 'bad route' logic
>    so that search results are much more accurate.
> 
> 5) Change readvertisement logic so that it now
>    readvertises most recent 1024 non-local ads.
> 
> 6) Increase netcode efficiency (might reduce CPU,
>    and increase throughput on unlimited connections).
> 
> The automatic switching of routes on failed downloads
> hasnt been implemented in this release.
> 
> V0.15 is *not* backwardly compatible with V0.14 although
> V0.14 clients may be able to connect and advertise files,
> the files will be corrupted while downloading. So, we
> all need to switch to V0.15 at near enough same time.
> 
> I propose switching tonight at midnight Saturday (EST)
> if this gives Erik enough time to update the web page,
> and Luke and Michael enough time to switch  the servers
> to V0.15.
> 
> Remember, V0.15 hasnt been well tested so there is a
> small possibility we need to roll back to V0.14 if
> something major is broken that cant be fixed quickly,
> so let me know if you notice anything odd.
> 
> thanks to all concerned,
> 
> 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
> 

[Blocks-development] V0.15 is here!

[Blat F. <pet...@ho...>]

Well, V0.15 is ready and the following changes have been implemented...

1) All whole now multiple uploads capability for
   bulk uploading.

3) Add content hash to adverts and header blocks,
   and display this in the serach window.

2) Fix timeouts and problems when uploading &
   downloading at the same time.

4) Increase the smartness of the 'bad route' logic
   so that search results are much more accurate.

5) Change readvertisement logic so that it now
   readvertises most recent 1024 non-local ads.

6) Increase netcode efficiency (might reduce CPU,
   and increase throughput on unlimited connections).

The automatic switching of routes on failed downloads
hasnt been implemented in this release.

V0.15 is *not* backwardly compatible with V0.14 although
V0.14 clients may be able to connect and advertise files,
the files will be corrupted while downloading. So, we
all need to switch to V0.15 at near enough same time.

I propose switching tonight at midnight Saturday (EST)
if this gives Erik enough time to update the web page,
and Luke and Michael enough time to switch  the servers
to V0.15.

Remember, V0.15 hasnt been well tested so there is a
small possibility we need to roll back to V0.14 if
something major is broken that cant be fixed quickly,
so let me know if you notice anything odd.

thanks to all concerned,

PG.

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

Re: [Blocks-development] V0.15 readvertisement of locally cache files

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: Re: [Blocks-development] V0.15 readvertisement of locally cache 
>files
>Date: Fri, 4 Aug 2000 18:17:57 +0200
>
>On 4 Aug 2000, at 13:33, Blat Froop wrote:
>
> > Here is an idea...
> >
> > at the moment the V0.15 is going to readvertise the most
> > recent 1024 non-local file advertisements to newly connected
> > servers. Local files are not rebroadcast in order to stop
> > people connecting to see what you are serving directly.
> >
> > So, what if I change it so that V0.15 makes up a bogus random
> > single character route for each locally cached file. Then
> > connecting clients wont be able to tell if the server has it
> > itself, or one immediately adjacent to it. The bogus route
> > will be valid since the server will intercept requests it
> > can furfill out of cache.
>
>Wouldn't that lead to problems if the servant disconnects, or other
>servants connect to the servant that receives the bogus routes, where
>it is readvertised?

The 'readvertisements' wouldnt be broadcast. But, yes, eventually
when slow readvertisements are implemented this might cause problems.

>
>What is the problem of not re-advertising local files? I thought they
>would remain in the network's "memory" because they are advertised by
>other hosts.

Yup, this is true, as well. Guess I was just thinking out loud...
V0.15 will simply readvertise non-local files.

ttfn

PG.

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

Re: [Blocks-development] V0.15 readvertisement of locally cache files

[Erik M. <mo...@sc...>]

On 4 Aug 2000, at 13:33, Blat Froop wrote:

> Here is an idea...
> 
> at the moment the V0.15 is going to readvertise the most
> recent 1024 non-local file advertisements to newly connected
> servers. Local files are not rebroadcast in order to stop
> people connecting to see what you are serving directly.
> 
> So, what if I change it so that V0.15 makes up a bogus random
> single character route for each locally cached file. Then
> connecting clients wont be able to tell if the server has it
> itself, or one immediately adjacent to it. The bogus route
> will be valid since the server will intercept requests it
> can furfill out of cache.

Wouldn't that lead to problems if the servant disconnects, or other 
servants connect to the servant that receives the bogus routes, where 
it is readvertised?

What is the problem of not re-advertising local files? I thought they 
would remain in the network's "memory" because they are advertised by 
other hosts.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>