he CPU
load? What is the point? Freenet is so heavy anyway that it should probably
run at nice levels between 15 and 19, certainly not lower. Otherwise even
ridiculously powerful machines grind to a halt. Routing takes however long it
takes. If the node starts g
On Friday 26 September 2003 20:35, Edward J. Huff wrote:
> On Fri, 2003-09-26 at 12:08, Gordan wrote:
> > Of course, if the hashing function is complex enough to take 1 second to
> > calculate on modern hardware, then it will take 136 years of CPU time to
> > work out every
OTOH, if the list was public and the open relays got
abused ridiculously, maybe the admins of those servers would finally do
something about them... Somehow I doubt it...
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
a special deamon to handle such things.
I think that would be just too much work...
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
ly a part of a solution,
but more than one tool is needed to solve this problem sensibly.
Would anybody care to ask the people that used to run the Osirusoft, Monkeys
and CompuNet RBLs to move their RBL operations to Freenet?
Gordan
___
Devl mailing
d only be good for all keys under SSK@/colors/blue//
because that is the list the manifest has. It wouldn't work for
SSK@/colors/.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
On Thursday 25 September 2003 10:01, Tracy R Reed wrote:
> On Thu, Sep 25, 2003 at 09:43:59AM +0100, Gordan spake thusly:
> > Agreed. However, a patch to the MTA would be required to give it a
> > different mechanism for look-ups, e.g. one that looks up from a text
> > fil
en frankly, I'd
much rather not know what it is that is being hidden. This is not about
paranoia - the important part is that the public/private key pair would have
to take a very long time to generate, to make it way too expensive for
spammers, while keeping it acceptable for legitimate
n't contain one of your vaild email addresses, OR a valid email address
of one of the mailing lists you are willingly subscribed to, mark it as spam
and just bounce it there and then.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freene
for the whole lot, so milters are a _second_
line of defense.
But again, we are getting off topic.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
re sensible where spam has been outlawed, e.g. California as of
recently, they would probably support you, and the spammers would not be able
to find out who is doing it.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
s and online articles), but I don't really have
much sympathy for them.
Anyway, this is getting very off topic for a Freenet list.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
On Friday 19 September 2003 16:43, Some Guy wrote:
> > --- Gordan <[EMAIL PROTECTED]> wrote
> >
> > > http://entropy.stop1984.com/en/p2p.html
> > > The question is in the routing.
> >
> > But if they use compatible FNP, then the routing
> > s
On Friday 19 Sep 2003 13:42, Some Guy wrote:
> --- Gordan <[EMAIL PROTECTED]> wrote
>
> > > I think Freenet's HSK,KSK, and SSK may become a
> > > standard. Entropy is evidence of this.
> >
> > If that is the case, then it should not take much to
plemented, while the data storage resources are merged.
That would stimulate the nodes in the network to pick the best nodes for
routing to/through. This would in effect, make the a good testing tool for
finding what routing algorithm yields the best performance in terms of data
retrievability and speed. The chances are that the dominant implementation of
routing among the nodes in the routing table(s), relative to the proportion
of deployment of each implementation, would be very indicative of what the
best routing implementation is.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
On Thursday 18 Sep 2003 20:21, Michael Schierl wrote:
> On Thu, 18 Sep 2003 18:55:13 +0100, Gordan wrote:
> > On Thursday 18 September 2003 18:39, Michael Schierl wrote:
> >> Try to let FIW build the container for you or use the "insert a
> >> file/NIM" func
key?
e.g.
SSK@/SomeSite//a.zip//a0.html
SSK@/SomeSite//a.zip//a1.html
...
SSK@/SomeSite//z.zip//z9.html
Is there a reasonable way to achieve this? Effectively, treat all zips as
containers by default?
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
However, saying:
[EMAIL PROTECTED],ZSuhFw6jeLEj2AXY0ImzRA/test.zip//test.html
returns a message saying that the file doesn't exist.
What gives? I'm using unstable 6194.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
I seem to remember seeing this mentioned on this list some time ago, but I
can't remember the details. I tried uploading a zip, then accessing contents
using mycontainer.zip//myfile but that doesn't seem to work.
What tools support container based insert
ppens with a node that has a 500GB data store, fat network
connection, and has accumulated so much data that it doesn't specialise any
particular subspace? Does that node get ignored due to lack of
specialisation, or does it get overloaded because other nodes see it as
specialising everything?
getting completely filled up, other than by coincidence? How do
non-specialised nodes get requests routed to them? Is it only a matter of
last resort, i.e. "I have some routing requests left, and none of the other
more specialised nodes found the data, so I'll have a
On Monday 15 Sep 2003 16:57, Todd Walton wrote:
> On Mon, 15 Sep 2003, Gordan wrote:
> > On Monday 15 Sep 2003 11:29, Some Guy wrote:
> > [routing]
> >
> > > One solution that was proposed to do this was to do
> > > "light insertions" or "inver
is counter productive to build such things into the node
when it is far more sensible to just handle it on the application level of
whatever your application is supposed to do.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
e.
>
> Check out
> http://localhost:/servlet/nodeinfo/internal/ftable
> on your own node.
OK, thanks for that. I'm feeling really stupid now. :-p
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
pload as needed. This is much less taxing on me and
> the system in general.
>
> For the most part annoymity is there, except that I
> know somewhere out there someone is downloading. If
> many people download the file will probably be cached
> by ot
d-type DoS attack on specific nodes or specific parts of
the key space. Plus, if it were possible, it is especially this type of
deliberately specialised node and it's neighbours that would be worst
affected.
Gordan
___
Devl mailing list
[EMAIL
On Monday 15 Sep 2003 16:57, Todd Walton wrote:
> On Mon, 15 Sep 2003, Gordan wrote:
> > On Monday 15 Sep 2003 11:29, Some Guy wrote:
> > [routing]
> >
> > > One solution that was proposed to do this was to do
> > > "light insertions" or "inver
ce).
Precisely my point. Correct tool for the job.
> I think the big
> problem you'll have is getting people to run a freenet
> node just to install something.
People will do it if there is no other medium that makes the content available
in their part of the wor
Bummer...
If this is all down to bug(s) in Sun's VM, what is the current state of
portability to Kaffe or GCJ? Do they have all the required features
implemented to run Freenet? At least these kinds of problems could be
debugged more easily...
Unexpected Signal : 11 occurred at PC=0x403A1580
Fu
On Saturday 13 September 2003 12:09, Tracy R Reed wrote:
> On Sat, Sep 13, 2003 at 12:05:38PM +0100, Gordan spake thusly:
> > Global mean traffic (queries per hour):8673.0444
> > Local mean traffic (queries per hour): 203160.27088036117
>
> I have noticed ludicr
node grind to a halt in minutes. Now it seems to be
working absolutely fine. This is clearly a very good build. :-)
1024 connections
256 threads
256 routing table size, and between 2/3 and 3/4 have connections open
I am impressed.
Gordan
___
Devl mailing
Java 1.4.2_01-b6 (latest)
RedHat 9.0 (pthreads disabled)
Freenet 6190
Unexpected Signal : 11 occurred at PC=0x403A1580
Function=(null)+0x403A1580
Library=/usr/java/j2re1.4.2_01/lib/i386/server/libjvm.so
NOTE: We are unable to locate the function name symbol for the error
just occurred. Pleas
On Thursday 04 September 2003 17:56, Toad wrote:
> On Thu, Sep 04, 2003 at 08:26:39AM +0100, Gordan wrote:
> > Is it normal for a node without any bandwidth throttling with about 1 Mb
> > of symmetric bandwidth to max out at under 16 KB/s (1/8 of the actual
> > available band
ckly
learn to route to the border node(s) instead of trying to route further in.
In fact, they won't even bother routing further in because the references
will have private IP addresses on them which will get dropped before making
it into the routing table in the first place. Or am I wrong here?
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
will typically continue to chug along this way until it is restarted,
at which point the cycle seems to repeat, i.e. max out the bandwidth, then
after an hour or so fall back down to overload speeds.
Gordan
___
Devl mailing list
[EMAIL
I've just had this happen (see attached file for the dump). For some bizzare
reason, it looks like pthread library was used even though
LD_ASSUME_KERNEL=2.4.1 was set.
Gordan
Unexpected Signal : 11 occurred at PC=0x403A1580
Function=(null)+0x403A1580
Library=/usr/java/j2sdk1.4.2/jre/lib
On Wednesday 03 September 2003 18:21, Dan Merillat wrote:
> On Wed, 03 Sep 2003, Gordan wrote:
> > I've got a hypothetical question, and am consequently looking for a
> > fairly theoretical answer.
> >
> > Say I have a bunch of nodes on a fast LAN, on private IPs (
requets would hopefully be fulfillable
> > over the fast LAN instead of the slow WAN.
>
> Yes. Hopefully the internal nodes would never forget about the border
> node. NGRouting has of course a much wider scope than this. Such
> setups may well be used in hostile environments... talk to jrand0m about
> that :)
jrand0m? Who is that?
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
world, the requets would hopefully be fulfillable over the
fast LAN instead of the slow WAN.
I hope this makes some sense.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
egotiating node is just dragging the network down
with it's own congestion... Sort of like remote node load balancing. ;-)
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
all together after
a few hours.
Gordan
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
Maybe a little bit off topic, but I think this may be relevant at some
point...
http://www.pdos.lcs.mit.edu/grid/software.html
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
bandwidth usage at all.
Has anybody else noticed similar behaviour? What has gone into Fred around the
6149/6150 mark that could explain this?
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo
type would pass through the system much like current
> messages, preserving anonymity. And since the index was of everything
> viewing locally and relayed the node operator still maintains plausible
> deniability.
So you still end up with the index uploaded i
ertion time.
However, this does not mean that the files will reside in the node that
inserted them.
In conclusion, the kind of index you are talking about could only be generated
at insertion time. Frost already does pretty much precisely this. Why
deal with things like roll-over
graphics. Now you are talking about creating an entire client-end application
in it. While it may be possible, there are issues that may be difficult to
overcome...
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
/limited the indices are, the less
> > useful they are.
> > The index that knows about more content is going to be the
> > index that more
> > people use. This pretty much sinks the concept of "I'll only
> > index these sites",
>
> TFE has more links than TFEE. Still I mostly use TFEE because I am not
> interested in some of the stuff that the TFE page provides.
That is beside the point. Once a clever index storage design can be found,
anybody who feels like it can run their own search engine site.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
ople to act as 'index
> publishers' and each and every user could choose whose indexes to
> 'search in'/'merge into their own local index' and trust, much like
> todays index pages
Sort of. The more segmented/limited
impossible by design.
However, content that is linked/advertised should be indexable by automated
crawlers.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
ion.
I have an issue with creating solutions that require external networks. This
is doable in Freenet on it's own, it just requires more thought about index
formating. 100% real-time low-latency solution is not necessarily required
for this problem. In fact, it is not required for mo
>
> There are many, many more technical difficulties involved in that than you
> may realize, especially in coming up with a good, scalable index format.
>
> On itself, it's rather simple, really. It is however, not unlimited
> scalable, that is true. but I really think, in the short to mid-long term,
> it would be a hit.
It would have to be scalable, i.e. it's speed would have to reduce
logarithmicaly with the amount of content, and the size of the index itself
would have to be such that it occupies the tiny fraction of the space
occupied by the content that it indexes. 10% of the size of the indexed
content would be bad. Get it down to 1%, and it might just work.
The problem, again, is in the index format.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
ep? I'm leaning toward the
> later now.
Not sure. Tell us in the morning. :-)
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
applet.
> Not ideal, perhaps, but untill a true good-working, scalable, anonymous
> searchengine is created to work in freenet, it would beat everything that
> is currently available on freenet.
There are many, many more technical difficulties involved in that than you may
realize, especially
On Thursday 14 August 2003 19:58, Tracy R Reed wrote:
> On Thu, Aug 14, 2003 at 06:47:11PM +0100, Gordan Bobic spake thusly:
> > It is the money laundering aspect that is problematic at the "link"
> > point. Coming up with a secure and anonymous on-line cash-token excha
Another option is to take a hash of the key (a hash of the hash) and base
specialisations and routing on that, rather than the first hash (key). This
would make it much more difficult to guess/generate keys in a part of the
keyspace, thus making it more difficult to Do
On Thursday 07 August 2003 23:02, Greg Wooledge wrote:
> Gordan ([EMAIL PROTECTED]) wrote:
> > Has anything happened very recently (since 6137+) that would explain a
> > drastic reduction in bandwidth consumption of my node? I have not changed
> > the limits, but
gt; hurt freenet's fragile ecosystem?
As long as their node capacity and bandwidth exceed the content they are
inserting, more nodes would always help, AFAIK.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
tic at the "link" point.
Coming up with a secure and anonymous on-line cash-token exchange protocol is
quite simple.
Gordan
On Thursday 14 Aug 2003 18:06, [EMAIL PROTECTED] wrote:
> I'm sure that the vast majority of us are computer nerds and, as such, have
> read t
u/bw at the computer (cronjob/etc)
> or some ticker job??
I thought of that, but inspection confirmed that was not the case.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
te-by-byte transfers are inefficient, I agree. Would it not be better, then
to do it packet-by-packet instead? It reduces the granularity, so it should
still work OK, even it is marginaly more bursty.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http:/
wrong with this behaviour, merely that
such a regular pattern seems odd.
This is not new, and I have been noticing this for as long as I have been
running a node.
Can anybody propose a theory that might explain this fenomenon?
Gordan<>
On Saturday 09 August 2003 15:42, Ian Clarke wrote:
> Is this still the case with 5023 - it has significant modifications to
> the BW limiting code.
I am running 6147.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.or
s showing the
simptoms, 6141 does not.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
w for sure there is
a reason for this before I start cranking up the b/w settings.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
l it what the mime type is. Additionally, mime type gets
passed by the browser when a file is uploaded, so this can be used, too.
Then, we can check the file's extension to try to determine the mime type.
Finally, mime type can often be determined by reading the first few bytes of
the file to
a unless the client looks at the MIME-types to
> determine suitability for compression.
I completely agree. This is precisely why I suggested detecting mime types and
skipping compression on files that are already compressed.
Gordan
___
devl mail
On Monday 04 Aug 2003 15:03, [EMAIL PROTECTED] wrote:
> On Mon, 04 Aug 2003 06:05:45 -0700 Gordan <[EMAIL PROTECTED]> wrote:
> >Are there any objections to the above spec, other than objections
> >to using any non-manual compression?
>
> I've been following this t
hin the network.
Are there any objections to the above spec, other than objections to using any
non-manual compression?
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
ill force text-based browsers to download
> unnecessary data, and we will lose the benefits of individual caching of
> images which are reused in different places.
I agree with that to a degree approaching 100%...
Gordan
___
de
On Friday 01 August 2003 22:55, [EMAIL PROTECTED] wrote:
> On Fri, Aug 01, 2003 at 05:30:51PM +0100, Gordan wrote:
> > On Friday 01 Aug 2003 17:08, J wrote:
> > > With all this discussion of using zip on the network as a standard, has
> > > anyone put any thought into ho
On Friday 01 Aug 2003 17:38, Edgar Friendly wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > >Is there any particular reason why the tool would do that on it's own?
> > > The node already has to do it regardless (am I correct in thinking
> > > that?), so doing it twice is wasteful.
>
>
So, to
improve bandwidth shortages we have to either increase the available
bandwidth (expensive and not always doable) or compress files that can be
compressed (much cheaper, and always doable, data format allowing).
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
AES, for example is not voulnerable to this type of attack, and even
CBC algorithms that are voulnerable can be made immune purely by pre-padding
the data with 256 bits of random noise.
I don't think this is a concern.
Gordan
___
devl mailing
pression
ratios on all files. That is what is going to be happening in the node.
I think the edge of bzip2 may go down in that case, but I am not sure by how
much.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
... if any data at all
See above. Under no sane protocol should algolrithm(data) yield variable
results when compression is concerned. Remember that the node software is the
only thing guaranteed to be the same on all nodes. This means that all
correct in thinking that?), so
doing it twice is wasteful.
> but both would add additional obfuscation to the protocols, which is bad
> for obvious reasons
>
> i'm glad it was just a discussion about the container compressor :)
I don't think it was...
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
much disruption, but at the same time, I must say that I am in favour of
getting it right the first time, rather than having to either fix things
later at an increased cost or just putting up with the sub-optimal
performance.
Gordan
___
devl mailing lis
> However I think that it ultimately comes down to the
> fact that zips are so much essayer to implement.
As I said, I am not sure that the difference will be that big. I don't think
the bzip2 library API will be that much more verbose than the built in Java
zip.
Gordan
___
to the
choice between better compression, and the convenience of a built-in library.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
he potential performance penalties in the long
term might be less signifficant than the data size reduction benefits.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
> If you are a freesite visitor: avoid visiting those sites.
> > >
> > > I am still not convinced that a 1MB limit is a good thing. It may be
> > > sensible to reduce this drastically.
>
> ?maxlogsize=18 limits files downloaded to fulfill a request to 256kB, in
that their
benefit/harm ratio might improve to the point where it is acceptable.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
ty pictures in WinZip is totaly irrelevant in this particular case.
Regards.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
On Wednesday 30 July 2003 19:03, Niklas Bergh wrote:
> > On Wed, 30 Jul 2003, Gordan wrote:
> > > Here is what I propose. ZIP archives to be replaced with tar archives.
>
> Why? Wouldn't an uncompressed/compressed zip be easier to produce since the
> required code alr
On Wednesday 30 July 2003 18:33, Todd Walton wrote:
> On Wed, 30 Jul 2003, Gordan wrote:
> > Here is what I propose. ZIP archives to be replaced with tar archives.
> > Then, on a lower, "node" level, at insert time, the file being inserted
> > is checked. If
ire no additional
libraries. The downside is that it generally doesn't seem to compress as well
as bz2, and sometimes the difference is quite noticable.
Thoughts please. :-)
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
d visiting those sites.
>
> I am still not convinced that a 1MB limit is a good thing. It may be
> sensible to reduce this drastically.
Thank you! :-)
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
t Ogg instead
of MP3 due to the fact that it has better quality (so I'm told) and there are
no legal/licencing/copyright/patent issues over using the encoding format.
Obviously, on the network level, the above "protocol" would support any file
format as long as the player does.
T
this might be any better
than a good hashing/specialisation function, but it's an idea anyway...
Let it never be said that thinking is not dangerous. ;-)
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
n 5017. The unstable version seems
to be doing a lot better.
> If your RT is not ridiculously large, mail me a thread dump (kill -QUIT
> `cat freenet.conf` and capture stdout).
I will do that if I notice the condition again. For now, v6115 seems to be
doing
with it. Usually this is easy to spot because it's bandwidth consumption
drops to 0 and stays there. It doesn't appear to be a recoverable condition.
The number of threads goes up, and up, and up, until either the machine runs
out of resources a
1
freenet.node.states.request.RequestInitiator93
The big problem seems to be in far too many
freenet.OpenConnectionManager$ConnectionJob instances being spawned.
Can anybody offer any insights? Has anyone seen similar behaviour?
Gordan
___
devl mailing l
portantly, will it
be enforced? Arguably, it should be enforced by the node, to prevent network
abuse.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
al, you can use it or you can
> abuse it.
Additionally, because the container is not going to be split-filed
redundantly, I think it would be more likely to go missing than the smaller
files. This means that instead of the page missing a few components, it
On Friday 25 July 2003 21:11, fish wrote:
> On Fri, Jul 25, 2003 at 08:05:39AM +0100, Gordan wrote:
> > On Friday 25 July 2003 03:06, Tom Kaitchuck wrote:
> > > On Thursday 24 July 2003 06:58 pm, Gordan wrote:
> > > > In that case let's limit it to 64 KB or 128 K
via
> other means.
I completely agree. But with allowing for things like the active link, the
main page, and up to 1 MB of the rest of the site to be pre-cached via an
archive in exactly this fashion, isn't that precisely what would be achieved?
Gordan
__
tibility is bad when it drags and lingers
on indefinitely.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
gt; > very quickly.
>
> No, it will REDUCE the network traffic - one large file instead of fifty
> small files.
If I understand how this works at the moment, it will reduce the number of
requests, but not the volume of transfers. At least not signifficantl
k of
> other issues to solve. And I don't regard it as a priority, I am more
> concerned with fixing routing :)
Fair enough. Speaking of routing, I used to have a very consistently "green"
routing table a few months back. Nowdays, it is doing well if there are even
2-3 gre
the handling of things. The concept of transferring
around 1 MB files just to load the splash screen is conceptually wrong.
64-128MB might just be acceptable.
Gordan
___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
1 - 100 of 119 matches
Mail list logo
