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