On Thu, Nov 06, 2003 at 02:24:52AM +, Toad wrote:
Why? Accesses from localhost are unlimited anyway. This setting only
affects runners of public nodes.
Not all of us run fred on their desktop machines..
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL
to me)
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|dse.nl] ICQ#10074100 1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
a useful metric.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|dse.nl] ICQ#10074100 1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
then there's actually been, seeing as the node doesn't handle much more
than 4k-5k qph.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|dse.nl] ICQ#10074100 1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED
).
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|dse.nl] ICQ#10074100 1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
___
Devl mailing
.
Okay, so they'd be punished in the estimators - the probability of DNF
for a given key would be updated on the graph?
Yes. I can't imagine this being a big deal, as a same request in the current
system with a HTL that would make it end without looping would punish that
node too.
--
Frank v
all incoming
requests to new requests with a higher HTL in an effort to return data
in a specific key area (within the bounds of time limits ofcourse)
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|dse.nl] ICQ#10074100 1FF3
a network would be harder, yes, but still not impossible.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|dse.nl] ICQ#10074100 1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
a network using such a crazy algorithm.
Ehm, no. You don't continue until the key is found, you continue until
the request gets routed to a node that that request has already passed,
ie the request loops.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED
force it to overload?
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|dse.nl] ICQ#10074100 1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
unencrypted content to the temp
dir, so just put your stuff there, and add a big warning to the readme
that the tempdir should be somewhere safe, ie on an encrypted disk or purely
in RAM, or just on a disk that gets scrubbed on shutdown, depending on
what your demands are.
--
Frank v Waveren
cache people happy, it would also lead to faster
specialisation, as the decision whether to throw away a piece of data
is done later when more information about the current
(datastore-)specialisation is available.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL
On Fri, Jul 25, 2003 at 02:42:35AM +0100, Toad wrote:
[connection mux]
Comments?
Sounds good, and should also make freenet play ever so slightly nicer
with the network as it's only got one tcp connection per node, which
makes it react to bandwidth restraints quicker.
--
Frank v Waveren
resolved my node freezing problem.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
'. Having every node along
the way branch out would put a lot more stress on the network and make
requests take a lot longer to complete.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
very wrong information. Including all of page 5 (diagram included).
well, perhaps I'm wrong, it's too warm here to check the source :).
I'll wait for Ian/Matthew to confirm/deny...
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl
http://freenetproject.org/image/histanim.mng now has a mimetype of
text/plain according to http://freenetproject.org, which obviously
confuses even the browsers that do understand MNG.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl
problem with Opera. Have you tried
mozilla? I've had good results with that.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED
, not less.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
committed. In future, unified diffs are preffered, as what the website
serves up isn't exactly the same as the files on server. Or better
yet, get Ian to give you a CVS account, he's constantly recruiting
people who look like they might ever want to touch the website.
--
Frank v Waveren
times the value you want it to be.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
On Wed, Jul 02, 2003 at 01:25:00AM -0400, Colin Davis wrote:
Precompiled wget for windows- http://space.tin.it/computer/hherold/
Wget would be a bad choice unless someone fixes it so it doesn't
compress multiple slashes into one anymore.
--
Frank v Waveren
that?) with java version 1.4.1_02 on Linux.
You don't happen to have a low maximum filesize (RLIMIT_FSIZE)
resource limit?
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp
On Mon, Jun 16, 2003 at 04:27:51PM -0700, Tracy R Reed wrote:
bash-2.05b$ ulimit -n 4096
bash: ulimit: open files: cannot modify limit: Operation not permitted
You cannot increase ulimits above your hard resource limit unless you
are a privileged user, see man setrlimit.
--
Frank v Waveren
VED.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0 3AC1 6DF2
___
devl ma
un jvm. A little better
actually, as it does userspace threading.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0 3AC
rashed quite frequently.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0 3AC
On Sun, May 18, 2003 at 07:30:22PM -0400, Greg Wooledge wrote:
> Then why do some operating systems have freenet.conf, and some freenet.ini?
It reads both on all platforms (and also .freenetrc), the freenet.ini
file is created by the (non-crossplatform) installer.
--
Frank v Wave
), you
shouldn't consider telling the JVM that it can only have so much
memory as a way of limiting fred's memory usage, but more of a "I
don't want fred to spin out of control and make my entire system
unusable, stop it if it tries to use more than this".
--
s
nice tasks a little more, and having it do all slices equally long.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.
0 0 0 306 56 77 0 0 100
0 0 13 606912 22528 0 0 0 0 0 0 0 0 0 0 0 310 63 81 0 0 100
0 0 13 606912 22528 0 0 0 0 0 0 0 0 0 0 0 306 56 70 0 0 100
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|che
it starts up, and populate it with the same image files served by the
> servlet.
Not everybody runs fred on the same machine as the one they run
clients/the browser on.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100
lds should make sense to be allowable.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0 3AC1 6
lds should make sense to be allowable.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0 3AC1 6
should make sense to be allowable.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
-lnux-x86.jar, added it to my classpath, restarted
freenet and it worked (no config changes necessary anymore). Ofcourse
then it started crashing every 20 minutes and I removed it again, but
it does work in principle.
--
Frank v Waveren Fingerprint: 21A7
, added it to my classpath, restarted
freenet and it worked (no config changes necessary anymore). Ofcourse
then it started crashing every 20 minutes and I removed it again, but
it does work in principle.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL
On Wed, Mar 19, 2003 at 01:48:10AM +, Matthew Toseland wrote:
> "loglevel warning" ? There is no "warning", there is only debug, minor,
> normal, error IIRC
Ah, so there is. Oops.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@
On Wed, Mar 19, 2003 at 01:48:10AM +, Matthew Toseland wrote:
loglevel warning ? There is no warning, there is only debug, minor,
normal, error IIRC
Ah, so there is. Oops.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl
Even at loglevel warning and higher my log is still filled with
debugging messages in the trunk CVS version. Could this be due to the
usage of 'Logger.DEBUG' in many places while Logger.java only lists
Logger.DEBUGGING?
--
Frank v Waveren Fingerprint: 21A7
Even at loglevel warning and higher my log is still filled with
debugging messages in the trunk CVS version. Could this be due to the
usage of 'Logger.DEBUG' in many places while Logger.java only lists
Logger.DEBUGGING?
--
Frank v Waveren Fingerprint: 21A7
0.5.0
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0 3AC1 6DF2
___
devl mailing
download it implies that
> nobody else will either
Not necessarily, it merely increases the probability. But in many
cases, just having everybody propagate what they can will mean in the
end everybody gets the file.
--
Frank v Waveren Fingerprint: 21A7 C7F3
download it implies they
want it.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0
0.5.0
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
start. But I think continuing the download even if it's
not going to succeed is more of a service (if the downloader is truly
interested in the file) than a burden for the network, and I think it
should be presented as such to the end user.
--
Frank v Waveren
it implies they
want it.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
it implies that
nobody else will either
Not necessarily, it merely increases the probability. But in many
cases, just having everybody propagate what they can will mean in the
end everybody gets the file.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL
solution is just
piping it through sed if you prefer your ip.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1
ey can get their hands on.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0 3AC1 6DF2
__
their hands on.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
continuing the download even if it's
not going to succeed is more of a service (if the downloader is truly
interested in the file) than a burden for the network, and I think it
should be presented as such to the end user.
--
Frank v Waveren Fingerprint: 21A7 C7F3
to direct these kind of questions to
freenet-support..
java -cp /path/to/freenet.jar:/path/to/freenet-ext.jar freenet.client.cli.Main
will list the params/commands you can give. Be sure to specify a
proper tmpDir and healPercentage.
--
Frank v Waveren Fingerprint:
> at once and stick-em together, but that would clearly be a bad thing).
Why? There's no magic involved in the joining of segments, so just
store them all to tempfiles and then read through them sequentially?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var
This is java version "1.4.1_02", and a CVS from a few days ago btw, as
always.
On Thu, Mar 06, 2003 at 02:13:11AM +0100, Frank v Waveren wrote:
> Inserting with the freenet.client.cli.Main put, I occassionally get
> the following errors:
>
> INSERTING_BLOCKS (174/192):[4/6]
, but this is the 3rd time it's
happened inserting the same (rather large) file.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9
these kind of questions to
freenet-support..
java -cp /path/to/freenet.jar:/path/to/freenet-ext.jar freenet.client.cli.Main
will list the params/commands you can give. Be sure to specify a
proper tmpDir and healPercentage.
--
Frank v Waveren Fingerprint: 21A7 C7F3
, but this is the 3rd time it's
happened inserting the same (rather large) file.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED
-em together, but that would clearly be a bad thing).
Why? There's no magic involved in the joining of segments, so just
store them all to tempfiles and then read through them sequentially?
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl
downloads of Freenet
0.4 SplitFiles
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0
On Sat, Mar 01, 2003 at 02:56:06PM +, Matthew Toseland wrote:
No way, it works here, and we wouldn't hold a lock over the ENTIRE
request. There might well be a lock waiting for the actual FEC
encoding/decoding though. Get a thread dump.
For your viewing pleasure.
--
Frank v Waveren
normal
splitfile downloads start within seconds). Also, I can download
splitfiles without problems with 20-30 download threads, but two
splitfiles with one download thread each will hang.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl
connections where closed. I suppose this is probably some
sort of lock contention issue.. I don't suppose there's a way of
convincing java to spit out all currently held locks? (preferrably in
a signal handler, but I don't know if java does those either :-) )
--
Frank v Waveren
Don't know if this is already known, but there's a small cosmetic bug
in the node status interface for histogram of sizes of keys in
datastore: The histogram is correctly labled as sizes, but the peaks are
labled as keys (ie 123...def).
--
Frank v Waveren
level log is available at http://www.var.cx/freenet.log.gz,
or [EMAIL PROTECTED],YZayAxh3TDM5Qy~rpMW22w
If anyone could shed some light on this it'd be much appreciated.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#10074100
might be useful, however..
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
you your IP.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
is a piece
of sh*t, which is just a bad idea.
--
Frank v Waveren Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
On Fri, Feb 21, 2003 at 01:03:40AM +0100, Michael Schierl wrote:
BTW: What does ARK and TUK stand for (Address R??? Key, T??? Update
Key?)
address resolution key, time updatable key.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl
, Matthew has a huge backlog
of messages. Perhaps he could procmail messages that need to be
moderated to bounce?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL
On Mon, Feb 17, 2003 at 07:29:03PM -0500, bdonlan wrote:
java freenet.client.cli.Main put -m name of empty file CHK@
filename to reinsert
Why not add a --noMetadata flag?
Wouldn't -m /dev/null work? Or doesn't java like that?
--
Frank v Waveren
On Mon, Feb 17, 2003 at 08:28:37PM -0500, Bryan Donlan wrote:
Wouldn't -m /dev/null work? Or doesn't java like that?
Valid point. Perhaps on the DOS based windowses you could use the NULL
device, but apart from that, yes you're right :-)
--
Frank v Waveren
..
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
___
devl mailing list
[EMAIL
you could change all file
renames to use a proper file-moving method (which you'd probably have
to write yourself )-:).
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL
.
Since java does not know what a filesystem is, this is borken - what JVM
are you using? Hmm. Apparently this is in the java spec(!!!):
Sun 1.4.1-b21. Do you mean the spec is broken, or the JVM doesn't follow
the spec?
it turns out the spec is broken.
--
Frank v Waveren
of the memory
used is RO pages from mapped jvm executables and libs and can thus be
shared between jvms on most OSes?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL PROTECTED
I think matthew already squashed the bug, something with the logger
writing 20 08 to check if the stream was writable. Fix is in CVS, I'll
leave it to him to explain proper if anyone wants it.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl
t connections and such).
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx7BD9 09C0 3AC1 6DF2
___
and such).
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
___
devl mailing list
[EMAIL
Am I correct in reading that one of the changes between protocol
version 0.4 and 0.46 was the abolishing of ElGamal in favour of DLES?
Was this done only for the greater cryptographic strength of DLES or
where there other reasons for changing?
--
Frank v Waveren
Am I correct in reading that one of the changes between protocol
version 0.4 and 0.46 was the abolishing of ElGamal in favour of DLES?
Was this done only for the greater cryptographic strength of DLES or
where there other reasons for changing?
--
Frank v Waveren
instead of
SSK at
nTfrw2k-BectmzotDpQz1aNW2i4PAgM/FreeSpyder//all.htm?date=20030119-22:00:00.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx
see also my post about fred sending one-byte packets)
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw at var.cx
-byte packets)
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
___
devl mailing
I noticed that on the wire the first two bytes fred sends on making an
outgoing connection are sent in seperate packets, which isn't exactly
efficient. Is this necessary design-wise or something that can't be
avoided due to jvm's?
--
Frank v Waveren
I noticed that on the wire the first two bytes fred sends on making an
outgoing connection are sent in seperate packets, which isn't exactly
efficient. Is this necessary design-wise or something that can't be
avoided due to jvm's?
--
Frank v Waveren
? Making a seperate class just for this seems like overkill
though, is there some general utilities class it could go into?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwk
for this seems like overkill
though, is there some general utilities class it could go into?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL PROTECTED]7BD9 09C0
a reasonable tempDir be passed via the constructor.
The last seems the most viable, but is still far from nice. Any better
suggestions?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key
same bug crept back in to the code as happened with 543,
with which quite a few people where having this problem.
Matthew, could you check if hawk "f*ck up" again?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074
back in to the code as happened with 543,
with which quite a few people where having this problem.
Matthew, could you check if hawk f*ck up again?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C
), as the actual full requested URI isn't available.
1) Do you agree this is a bug?
2) How would one go about fixing it without getting into ugly hacks?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C
not trojaning you later..
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp:[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
a reasonable tempDir be passed via the constructor.
The last seems the most viable, but is still far from nice. Any better
suggestions?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key
eeing this too, (Build 543, which as of five seconds ago was
freenet-latest.jar). It appears all tag attributes are being stripped
( becomes ). This for starters makes all images and
links duds, so it shows up on all sites, TFE for instance...
--
Frank v Waveren
http://freenetproject.org appears to be slightly ill, and giving
Internal Server Errors. The error page says to inform staff at sf.net,
but I assume it's to do with freenetproject.org's twiki setup?
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx
seconds ago was
freenet-latest.jar). It appears all tag attributes are being stripped
(foo bar=baz becomes foo). This for starters makes all images and
links duds, so it shows up on all sites, TFE for instance...
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw
On Tue, Dec 31, 2002 at 08:25:54AM -0500, Ed Tomlinson wrote:
> Try setting
>
> outputBandwidthLimit=6000
>
> to limit to 6K/sec
The 'outputBandwidthLimit=1' was just an example to show it doesn't
work, it doesn't work at higher settings either.
--
imit=0
%averageOutputBandwidthLimit=0
> You should upgrade to 1.4.1r01.
Done, though no change on the bandwidth front.
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#100741001FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw
On Tue, Dec 31, 2002 at 08:25:54AM -0500, Ed Tomlinson wrote:
Try setting
outputBandwidthLimit=6000
to limit to 6K/sec
The 'outputBandwidthLimit=1' was just an example to show it doesn't
work, it doesn't work at higher settings either.
--
Frank v Waveren
1 - 100 of 102 matches
Mail list logo
