On 24/05/2004, at 11:32 PM, Wayne McDougall wrote:

Phillip Hutchings <[EMAIL PROTECTED]> writes:

One thing that I can think of is limiting the size of incoming files
not requested by the node directly - stop splitfiles and things going
through. I'm more interested in the information, not movies, but I
can't think of a tidy way to implement this in a few minutes. I know
it's not really in line with the freenet ideal, and also it could
compromise privacy, but it's a thought.

So you not only don't want to store large files in your data store -
you don't want to relay them either? It should be easy enough to stop such
files being stored in your data store - according to freenet.ini it doesn't
store files larger than 1/100th of the size of your datastore, in your
datastore. That 1/100 calculation would be easy to find and tweak so you don't
store files of 1 Mb (and these days all the large files I see are in chunks of
1,026 Kb). The question is whether you can identify whether incoming data is
part of an incoming 1 Mb message bfore you accept it. My guess, only a guess,
is yes.

I would think that "information" as opposed to files would normally be under 1
Mb.

For my part I'd like to contribute as much bandwidth to Freenet as a whole, but
when in a capped triage situation I certainly understand wanting to prioritise
traffic.

I don't care about storing things on my node - I have a 4GB store - but I do care about the traffic used by them. When freenet uses over 1/10th of my monthly cap in a day it gets shut down.

Personally, I've only seen movies bigger than 1MB, most text pages are 20-400KB (TFE's index page was ~400KB last time I looked).
--
Phillip Hutchings
[EMAIL PROTECTED]
http://www.sitharus.com/

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Reply via email to