Re: Racist statement of Ian Clarke on this list

Oops, forgot to mention my Twitter handle is "zlatinb". Good luck! On Fri, Jan 27, 2023 at 10:54 AM Zlatin Balevsky wrote: > Hello everyone, > > My name is Zlatin Balevsky. I was involved in the development of Freenet > sometime around 2001-2003. I've kept a relative

Re: Racist statement of Ian Clarke on this list

Hello everyone, My name is Zlatin Balevsky. I was involved in the development of Freenet sometime around 2001-2003. I've kept a relatively close eye on what's been going on since then. I want to say that I consider Ian Clarke / Sanity a great man, and even though I've never met him in person

Re: [freenet-dev] Project Status

can bring more volunteers passionate about it, so all venues are worth pursuing :) zab/topiltzin On Thu, Oct 15, 2015 at 8:57 PM, Matthew Toseland <mj...@cam.ac.uk> wrote: > On 15/10/15 20:40, Zlatin Balevsky wrote: > > I first got involved in Freenet when it was 0.2. At the time i

Re: [freenet-dev] Behind the times

There exists a pure java implementation of a Tor client - https://subgraph.com/orchid/index.en.html apologies if this has already been brought up, searching archives is hard (TM) On Mon, Oct 12, 2015 at 9:41 AM, xor wrote: > On Tuesday, October 06, 2015 09:10:28 AM Ian

Re: [freenet-dev] Behind the times

As a random external java developer looking to possibly contribute, I'd much prefer dealing with a Gradle script than Ant/Maven. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] circumvention tools hackfest in NYC in July

Anyone in NYC and nearby area check out http://openitp.org/?q=circumvention_tools_hackfest_nyc_july_2012 I'll try to stop by

[freenet-dev] circumvention tools hackfest in NYC in July

Anyone in NYC and nearby area check out http://openitp.org/?q=circumvention_tools_hackfest_nyc_july_2012 I'll try to stop by ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Offer to help with Windows installer

Hi Jeff, what is your preferred installer tool? It would be great to 1. automatically install a recent jre 2. use pack200 compression for the jars. If you plan on using NSIS I can share some script snippets that kind of do this. On Sat, Nov 26, 2011 at 9:45 AM, Jeff Rivett wrote: >

Re: [freenet-dev] Offer to help with Windows installer

Hi Jeff, what is your preferred installer tool? It would be great to 1. automatically install a recent jre 2. use pack200 compression for the jars. If you plan on using NSIS I can share some script snippets that kind of do this. On Sat, Nov 26, 2011 at 9:45 AM, Jeff Rivett jriv...@shaw.ca

[freenet-dev] Statistics Project Update #4

> > On 06/19/2012 04:10 PM, Matthew Toseland wrote: > > However, DoS protection should be a little stronger than has been > > discussed: You should limit the average number of probes on a > > given link per unit time, like we do with swapping. This should > > probably be an average, and should be

Re: [freenet-dev] Statistics Project Update #4

On 06/19/2012 04:10 PM, Matthew Toseland wrote: However, DoS protection should be a little stronger than has been discussed: You should limit the average number of probes on a given link per unit time, like we do with swapping. This should probably be an average, and should be generous

[freenet-dev] Statistics Project Update #4

> > On 05/23/2012 10:47 PM, Zlatin Balevsky wrote: > > On a global scale, the if the rate of new probe requests is higher > > than the rate at which existing ones expire the number of active > > probes at any moment will not reach balance. Higher HTL makes a > > dd

Re: [freenet-dev] Statistics Project Update #4

On 05/23/2012 10:47 PM, Zlatin Balevsky wrote: On a global scale, the if the rate of new probe requests is higher than the rate at which existing ones expire the number of active probes at any moment will not reach balance. Higher HTL makes a ddos against the probe mechanism easier

[freenet-dev] Statistics Project Update #4

>> IMHO maximum HTL should be single-digits or you risk flooding. > > I don't follow. What do you mean? At each hop a probe either stays > locally (if a candidate is not accepted) or is routed to another > random node. On a global scale, the if the rate of new probe requests is higher than the

[freenet-dev] Statistics Project Update #4

Are these rate-limited in any way? Do they obey some general rate-limiting policies together with other messages? IMHO maximum HTL should be single-digits or you risk flooding. Does fred have any metrics collection system that would allow us to detect such flooding events? On Sat, May 19,

Re: [freenet-dev] Statistics Project Update #4

Are these rate-limited in any way? Do they obey some general rate-limiting policies together with other messages? IMHO maximum HTL should be single-digits or you risk flooding. Does fred have any metrics collection system that would allow us to detect such flooding events? On Sat, May 19,

[freenet-dev] Lantern

> "Desktop app" isn't necessarily a good thing. Generally true, but you're missing out on a lot of positive black swans with such position. Anybody given a thought to some kind of mobile app? A mobile app that connects to a Freenet node running at home and does something meaningful would

Re: [freenet-dev] Lantern

Desktop app isn't necessarily a good thing. Generally true, but you're missing out on a lot of positive black swans with such position. Anybody given a thought to some kind of mobile app? A mobile app that connects to a Freenet node running at home and does something meaningful would increase

[freenet-dev] Statistics Project Update #1

> On 04/28/2012 06:56 PM, Zlatin Balevsky wrote: >> In Gnutella we observed that long-lived nodes tend to be better >> connected and that they also cluster with other high-uptime nodes. >> If the same is true for Freenet it's a good idea to keep an eye for >> side effect

Re: [freenet-dev] Statistics Project Update #1

On 04/28/2012 06:56 PM, Zlatin Balevsky wrote: In Gnutella we observed that long-lived nodes tend to be better connected and that they also cluster with other high-uptime nodes. If the same is true for Freenet it's a good idea to keep an eye for side effects as you tweak the behavior. Good

[freenet-dev] Statistics Project Update #1

On Fri, Apr 27, 2012 at 10:34 PM, Steve Dougherty wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Here's an update on my progress on the statistics project for the > first week: > > The current probes are biased towards better-connected nodes: at each > hop they choose a random peer

Re: [freenet-dev] Statistics Project Update #1

On Fri, Apr 27, 2012 at 10:34 PM, Steve Dougherty st...@asksteved.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's an update on my progress on the statistics project for the first week: The current probes are biased towards better-connected nodes: at each hop they choose a

[freenet-dev] Improving build security against back-doors: Bytecode verification

> > It appears we can just compare the bytecode however. If you want to compare > the disassembly that's good too, but somebody should check the source. > > I have uploaded a basic version of a bytecode verification script called > verify-build to the "Maintenance scripts" repository on github.

Re: [freenet-dev] Improving build security against back-doors: Bytecode verification

It appears we can just compare the bytecode however. If you want to compare the disassembly that's good too, but somebody should check the source. I have uploaded a basic version of a bytecode verification script called verify-build to the Maintenance scripts repository on github.

[freenet-dev] Logging subsystem rewrite

>> >> Any patch with lazy evaluation will not cause problems in the "normal" >> case but will affect debugging Fred because turning on debug log level >> for a single class will cause all lazy parameters everywhere to be >> created. Before someone calls me out on this one I this is how you can

[freenet-dev] Logging subsystem rewrite

> ?If your 'solution' is trading 'jar > ?size' and 'readability' against run-time performance (for the common > ?case assuming logNORMAL), we won't merge it. Freenet is slow enough > ?as is. Any patch with lazy evaluation will not cause problems in the "normal" case but will affect debugging Fred

Re: [freenet-dev] Logging subsystem rewrite

 If your 'solution' is trading 'jar  size' and 'readability' against run-time performance (for the common  case assuming logNORMAL), we won't merge it. Freenet is slow enough  as is. Any patch with lazy evaluation will not cause problems in the normal case but will affect debugging Fred

Re: [freenet-dev] Logging subsystem rewrite

Any patch with lazy evaluation will not cause problems in the normal case but will affect debugging Fred because turning on debug log level for a single class will cause all lazy parameters everywhere to be created. Before someone calls me out on this one I this is how you can use lazy

[freenet-dev] Logging subsystem rewrite

There's still a predicate there. > > On 03-04-2012 20:49, Zlatin Balevsky wrote: > >> May I suggest a nice little script someone ( novice? ) could write, >> solve the logging problem and learning a thing or two about language >> theory in the process : >> >>

Re: [freenet-dev] Logging subsystem rewrite

is solved? There's still a predicate there. On 03-04-2012 20:49, Zlatin Balevsky wrote: May I suggest a nice little script someone ( novice? ) could write, solve the logging problem and learning a thing or two about language theory in the process : Transform: if (LOG.isLoggable(Level.DEBUG

[freenet-dev] Logging subsystem rewrite

May I suggest a nice little script someone ( novice? ) could write, solve the logging problem and learning a thing or two about language theory in the process : Transform: if (LOG.isLoggable(Level.DEBUG)) { } Into private static void logComplexComputation( ..

Re: [freenet-dev] Logging subsystem rewrite

May I suggest a nice little script someone ( novice? ) could write, solve the logging problem and learning a thing or two about language theory in the process : Transform: if (LOG.isLoggable(Level.DEBUG)) { some complex computation that wouldn't happen otherwise log results of

[freenet-dev] Logging in Fred

On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland wrote: > On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote: >> >> >> >> In 'log.info("Random message: %s", obj.toString())' evaluating >> >> 'obj.toString()' was what caused issues, not

Re: [freenet-dev] Logging in Fred

On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote: In 'log.info(Random message: %s, obj.toString())' evaluating 'obj.toString()' was what caused issues, not recycling it, or so I believe to remember

[freenet-dev] Logging in Fred

>> >> In 'log.info("Random message: %s", obj.toString())' evaluating >> 'obj.toString()' was what caused issues, not recycling it, or so I believe >> to remember. > > You don't need to call obj.toString() before calling log() - just pass the > object itself. Then the only overheads are: > 1)

[freenet-dev] Logging subsystem rewrite

> > But we use a static logging API anyway, and this works adequately well. I > have debugged stuff largely through logs in multi-node simulators, I > generally rely on the thread name to identify the node (e.g. the UDP receive > and send thread include the port number in the thread name). >

Re: [freenet-dev] Logging subsystem rewrite

But we use a static logging API anyway, and this works adequately well. I have debugged stuff largely through logs in multi-node simulators, I generally rely on the thread name to identify the node (e.g. the UDP receive and send thread include the port number in the thread name). It

Re: [freenet-dev] Logging in Fred

In 'log.info(Random message: %s, obj.toString())' evaluating 'obj.toString()' was what caused issues, not recycling it, or so I believe to remember. You don't need to call obj.toString() before calling log() - just pass the object itself. Then the only overheads are: 1) Calling the

[freenet-dev] Logging subsystem rewrite

There are many problems with https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 : line 25: the static field log should be volatile. It may work now and then but it's broken. Google "double-checked locking" for more info. Either that or synchronize it

Re: [freenet-dev] Logging subsystem rewrite

There are many problems with https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 : line 25: the static field log should be volatile. It may work now and then but it's broken. Google double-checked locking for more info. Either that or synchronize it

[freenet-dev] Logging in Fred

pears to not change by much even > if I increase the number of arguments (and objects created) to log_info. > > On 24/03/12 03:02, Zlatin Balevsky wrote: >> Your test has nothing to do with stack allocation because you never >> use the objects that you pass to the log_

[freenet-dev] Logging in Fred

23, 2012 at 11:02 PM, Zlatin Balevsky wrote: > Your test has nothing to do with stack allocation because you never > use the objects that you pass to the log_info method so JIT removes > them. ?Apply the following patch and see yourself create garbage in > both testWith and

[freenet-dev] Logging in Fred

", res[3]); -printSummary("log only", res[4], "log+work", res[5]); + +System.out.println(sideEffect); } public static void main(String[] args) { On Fri, Mar 23, 2012 at 10:48 PM, Ximin Luo wrote: > On 24/03/12 02:44, Zlatin Balevsky wrote: >>

[freenet-dev] Logging in Fred

until JIT stops printing. On Fri, Mar 23, 2012 at 10:28 PM, Ximin Luo wrote: > On 24/03/12 01:56, Zlatin Balevsky wrote: >> Not really. ?Here, I'll change my call to allocate everything on one level: >> >> ? while (true) { >> ? ? ? ? ? ? ? log(" list siz

[freenet-dev] Logging in Fred

parameters which are optimized with smaller methods in mind. Unless someone can offer a great syntactic improvement I recommend against home-brew frameworks. Aspects may be able to clean things up nicely though, I'd be very curious to see some examples. On Fri, Mar 23, 2012 at 9:56 PM, Zlatin Balevsky

[freenet-dev] Logging in Fred

how > little of a difference it makes in real terms (<5%). > > X > > On 24/03/12 01:15, Zlatin Balevsky wrote: >> You're right, the example you gave will put the arguments on the >> stack. ?I wanted to clarify Escape Analysis in its current form works >> only if a ne

[freenet-dev] Logging in Fred

oking at blog entries? Escape analysis has been around for > years. http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/357d4e2eb4dd > > On 23/03/12 02:06, Zlatin Balevsky wrote: >> My claim is based on day-to-day observations of hundreds of JVMs under >> various >> load sc

Re: [freenet-dev] Logging in Fred

/jdk6/hotspot/rev/357d4e2eb4dd On 23/03/12 02:06, Zlatin Balevsky wrote: My claim is based on day-to-day observations of hundreds of JVMs under various load scenarios. Your claim that modern JVMs do escape analysis is worthless as it shows that you have merely read some blog posts, and even

Re: [freenet-dev] Logging in Fred

On 24/03/12 01:15, Zlatin Balevsky wrote: You're right, the example you gave will put the arguments on the stack.  I wanted to clarify Escape Analysis in its current form works only if a new object doesn't exit the stack frame where it's created. Because of that, the moment you do something

Re: [freenet-dev] Logging in Fred

parameters which are optimized with smaller methods in mind. Unless someone can offer a great syntactic improvement I recommend against home-brew frameworks. Aspects may be able to clean things up nicely though, I'd be very curious to see some examples. On Fri, Mar 23, 2012 at 9:56 PM, Zlatin Balevsky

Re: [freenet-dev] Logging in Fred

JIT stops printing. On Fri, Mar 23, 2012 at 10:28 PM, Ximin Luo infini...@gmx.com wrote: On 24/03/12 01:56, Zlatin Balevsky wrote: Not really.  Here, I'll change my call to allocate everything on one level:   while (true) {               log( list size is {1} ,                 new Integer

Re: [freenet-dev] Logging in Fred

. On 24/03/12 03:02, Zlatin Balevsky wrote: Your test has nothing to do with stack allocation because you never use the objects that you pass to the log_info method so JIT removes them.  Apply the following patch and see yourself create garbage in both testWith and testWithout. --- Test2.java

[freenet-dev] Logging in Fred

a single thread, > the hash table is empty and the pressure on the GC is low. Still, differences > are very small. Plus, there's no overhead due to a dedicated logging thread. > > > On 22-03-2012 18:59, Zlatin Balevsky wrote: > > Double-digit millisecond pauses are not nothing.? They

[freenet-dev] Logging in Fred

r claim of "double-digit millisecond" pauses is worthless without some > benchmarking and actual numbers. Modern JVMs do escape analysis to avoid > heap > allocation and this helps especially for transient computations like in > logging. > > On 22/03/12 21:59, Zl

[freenet-dev] Logging in Fred

on is trivial. > > Log.info("{1} did {2}", > new Object(){ public String toString() { return ITEM_1; } }, > new Object(){ public String toString() { return ITEM_2; } } > ); > > Garbage collection with short-lived objects costs next to nothing. > > On 22/03

[freenet-dev] Logging in Fred

Constructing the logging strings is half of the problem. The amount of garbage they will generate will result in significantly more time in garbage collection pauses. Unless you figure out a way to mimic lazy evaluation you have to live with the isLoggable predicates. varargs are not an option

Re: [freenet-dev] Logging in Fred

evaluation is trivial. Log.info({1} did {2}, new Object(){ public String toString() { return ITEM_1; } }, new Object(){ public String toString() { return ITEM_2; } } ); Garbage collection with short-lived objects costs next to nothing. On 22/03/12 21:15, Zlatin Balevsky wrote: Constructing

Re: [freenet-dev] Logging in Fred

pauses is worthless without some benchmarking and actual numbers. Modern JVMs do escape analysis to avoid heap allocation and this helps especially for transient computations like in logging. On 22/03/12 21:59, Zlatin Balevsky wrote: Double-digit millisecond pauses are not nothing. They may

Re: [freenet-dev] Logging in Fred

no overhead due to a dedicated logging thread. On 22-03-2012 18:59, Zlatin Balevsky wrote: Double-digit millisecond pauses are not nothing.  They may be acceptable right now but unless you can offer a drastically cleaner syntax Fred should stick with predicates as they are handled much better

[freenet-dev] webui and accessibility

Just want to add JRuby to the list. Rails has lots of fans and third-party tools and it's under active development and supposedly on java 1.7 it runs faster than the C implementation. On Wed, Mar 7, 2012 at 11:23 AM, Nicolas Hernandez < nicolas.hernandez at aleph-networks.com> wrote: > Hello

Re: [freenet-dev] webui and accessibility

Just want to add JRuby to the list. Rails has lots of fans and third-party tools and it's under active development and supposedly on java 1.7 it runs faster than the C implementation. On Wed, Mar 7, 2012 at 11:23 AM, Nicolas Hernandez nicolas.hernan...@aleph-networks.com wrote: Hello Ian,

[freenet-dev] GSoC 2012

+1 you might just have a winner On Thu, Feb 16, 2012 at 1:32 PM, Ian Clarke wrote: > I'm not sure whether people would object to this, but I would quite like > to mentor a student to work on Tahrir under the umbrella of the Freenet > project. > > Thoughts? Opinions? Insults? > > Ian. > > > On

[freenet-dev] GSoC 2012

I'm not up to speed with specifics of the current Freenet codebase but I'd enjoy mentoring for general java/jvm development best practices. More so, I'd hate to see Freenet miss out on fresh talent. On Thu, Feb 16, 2012 at 1:12 PM, Florent Daigniere < nextgens at freenetproject.org> wrote: >

Re: [freenet-dev] GSoC 2012

I'm not up to speed with specifics of the current Freenet codebase but I'd enjoy mentoring for general java/jvm development best practices. More so, I'd hate to see Freenet miss out on fresh talent. On Thu, Feb 16, 2012 at 1:12 PM, Florent Daigniere nextg...@freenetproject.org wrote: Hi!

Re: [freenet-dev] GSoC 2012

+1 you might just have a winner On Thu, Feb 16, 2012 at 1:32 PM, Ian Clarke i...@freenetproject.org wrote: I'm not sure whether people would object to this, but I would quite like to mentor a student to work on Tahrir under the umbrella of the Freenet project. Thoughts? Opinions? Insults?

[freenet-dev] some observations on linux priorities & NativeThread

While chasing a 100% cpu usage bug on latest ubuntu with linux kernel 3.0.0-14, ( https://bugs.freenetproject.org/view.php?id=5336 ) Nextgens and myself verified that passing -XX:ThreadPriorityPolicy=42 to the jvm makes thread priorities work even without the NativeThread library. I'll report in

[freenet-dev] some observations on linux priorities NativeThread

While chasing a 100% cpu usage bug on latest ubuntu with linux kernel 3.0.0-14, ( https://bugs.freenetproject.org/view.php?id=5336 ) Nextgens and myself verified that passing -XX:ThreadPriorityPolicy=42 to the jvm makes thread priorities work even without the NativeThread library. I'll report in

[freenet-CVS] freenet/src/freenet/node/states/FNP NewDataRequest.java.BlackHole, 1.1, 1.2

Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP In directory sc8-pr-cvs1:/tmp/cvs-serv23667/src/freenet/node/states/FNP Modified Files: NewDataRequest.java.BlackHole Log Message: slightly smarter black hole, more work to follow Index: NewDataRequest.java.BlackHole

[freenet-dev] what would YOU do to help NGR?

Hello users, here is a small poll to let us know how willing you are to help us get NGR working. Please get in touch with us somehow (directly to amphibian @ dyndns.org, irc, this list, the support list, frost, etc.) to let us know which of the following best describes your willingness to

[freenet-dev] Re: Drone nodes was Re: what would YOU do to help NGR?

Remote access to everything on the web interface, AND LOGS. Remote setting of logLevel, logLevelDetail and perhaps other options. Automatic upgrading, perhaps with remote triggering, or perhaps on a timer. Basically we want a couple of hundred 'drone' nodes that we can experiment on, to try to

[freenet-dev] restoring qr due to bandwith on stable

stable isn't limiting its outgoing bandwith very well.. I've set it to 15k but it spikes over 30 often, and it also has hundreds of connections transmitting data, and the number of successfully retrieved keys is very small compared to the number of requested keys. Perhaps we could try

[freenet-dev] Re: Where now?

We already know that old stuff is subject to that attack No, we don't know if classic routing is. We suspect it might be to some degree, but we are not sure. pgp0.pgp Description: PGP signature ___ Devl mailing list [EMAIL PROTECTED]

[freenet-dev] Re: Where now?

Zlatin Balevsky wrote: We already know that old stuff is subject to that attack No, we don't know if classic routing is. We suspect it might be to some degree, but we are not sure. Fine, but that's not the point. The point is to make Joe User happy with stable so we don't kill off

[freenet-dev] stable net kicking ass

Ok, yesterday it didn't work - nodes didn't learn about each other, it was busy, etc. Today however, the request success ratio was more than 10% for a brand new node (18 out of 124 externally requested keys successful), and frost is chugging along (recorded a download speed of 100k at some

[freenet-dev] Errors in formulas

The very idea of using a formula for making decisions about routing has one major flaw and that is the innacuracy of the estimators. Unless a perfect estimator is developed which will give the exact value of a given variable, any formula will produce humonguous margin of error. As you know,

[freenet-dev] something we haven't seen for a long time...

Histogram of requested keys. This count has nothing to do with keys in your datastore Dec 1, 2003 1:39:01 AM keys: 478 scale factor: 0.4383561611175537 (This is used to keep lines 64 characters) 0 |=== 1 |== 2 | 3 |== 4

[freenet-dev] weird crash with 6348

After several hours of uptime but no interaction with the user (i.e. node was left overnight) when I decided to check out the web interface in the morning fred suddenly hang. No cpu whatsoever was used, and when I tried to get a stack dump I got: Fatal: Stack size too small. Use 'java -Xss'

[freenet-dev] 6348 - sharp specialization

After starting a brand new node with 6348 the outbound requests become sharply specialized in a matter of minutes. The incoming requests are of course in disaray, but hopefully when more nodes start running this code we'll finally see the coveted specialization *coughmergecough*

[freenet-dev] rateless codes

This idea may be rather unpopular, but too bad... :)) Rateless codes are like FEC except that they support infinite number of checkblocks, and the file becomes a stream. Simple implementation is just to wrap the checkblocks from fec in a repeating sequence and insert them in a

[freenet-dev] Re: rateless codes

This idea may be rather unpopular, but too bad... :)) Rateless codes are like FEC except that they support infinite number of checkblocks, and the file becomes a stream. Simple implementation is just to wrap the checkblocks from fec in a repeating sequence and insert them in a

[freenet-dev] Re: QueryReject patterns and NGRouting

One radical solution: Remove the code to reject queries when the bandwidth limit is exceeded! which returns us in the state 5010-5018 where the node has accepted umpteen transfers, each going at snail speed. Making that prevalent accross the network will be catastrophic. Another possibility is

[freenet-dev] polling sharing estimator data

This is an extention to the idea of keeping estimator data in the .refs which aims to bring more consistent worldview between the nodes. It works best if there is trust implemented between nodes, but will also bring some limited results without trust. At random interval the node asks a random

[freenet-dev] packet-level compression

We are often sending 10s of messages in a single packet; most of these messages are very similar (i.e. QRs). While each message in itself isn't well compressible because of the nature of the strings it contains, a packet with 20 messages could be compressed much better, resulting in reduced

[freenet-CVS] freenet/src/freenet/node/states/request Pending.java, 1.80, 1.81

Update of /cvsroot/freenet/freenet/src/freenet/node/states/request In directory sc8-pr-cvs1:/tmp/cvs-serv15769/src/freenet/node/states/request Modified Files: Pending.java Log Message: get rid of some yellowies Index: Pending.java

[freenet-CVS] freenet/src/freenet/node/states/request AwaitingStoreData.java, 1.27, 1.28 SendingReply.java, 1.25, 1.26 SendFinished.java, 1.12, 1.13 ReceivingInsert.java, 1.25, 1.26 RequestDone.java, 1.7, 1.8

Update of /cvsroot/freenet/freenet/src/freenet/node/states/request In directory sc8-pr-cvs1:/tmp/cvs-serv16347/src/freenet/node/states/request Modified Files: AwaitingStoreData.java SendingReply.java SendFinished.java ReceivingInsert.java RequestDone.java Log Message: get rid of

[freenet-CVS] freenet/src/freenet/node/states/FNP NewDataRequest.java, 1.7, 1.8 NewInsertRequest.java, 1.7, 1.8

Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP In directory sc8-pr-cvs1:/tmp/cvs-serv16939/src/freenet/node/states/FNP Modified Files: NewDataRequest.java NewInsertRequest.java Log Message: get rid of some yellowies Index: NewDataRequest.java

[freenet-CVS] freenet/src/freenet/support FileLoggerHook.java, 1.36, 1.37

Update of /cvsroot/freenet/freenet/src/freenet/support In directory sc8-pr-cvs1:/tmp/cvs-serv16635/src/freenet/support Modified Files: FileLoggerHook.java Log Message: get rid of some yellowies Index: FileLoggerHook.java

[freenet-CVS] freenet/src/freenet/node/states/FCP NewClientGet.java, 1.10, 1.11 ReturnDiagnostics.java, 1.5, 1.6 NewClientPut.java, 1.14, 1.15

Update of /cvsroot/freenet/freenet/src/freenet/node/states/FCP In directory sc8-pr-cvs1:/tmp/cvs-serv17214/src/freenet/node/states/FCP Modified Files: NewClientGet.java ReturnDiagnostics.java NewClientPut.java Log Message: get rid of some yellowies Index: NewClientGet.java

[freenet-CVS] freenet/src/freenet/node/states/data ReceiveData.java, 1.24, 1.25 SendData.java, 1.32, 1.33

Update of /cvsroot/freenet/freenet/src/freenet/node/states/data In directory sc8-pr-cvs1:/tmp/cvs-serv17682/src/freenet/node/states/data Modified Files: ReceiveData.java SendData.java Log Message: get rid of some yellowies Index: ReceiveData.java

[freenet-CVS] freenet/src/freenet/node/states/announcing CompleteAnnouncement.java, 1.11, 1.12 Announcing.java, 1.37, 1.38

Update of /cvsroot/freenet/freenet/src/freenet/node/states/announcing In directory sc8-pr-cvs1:/tmp/cvs-serv17793/src/freenet/node/states/announcing Modified Files: CompleteAnnouncement.java Announcing.java Log Message: get rid of some yellowies Index: CompleteAnnouncement.java

[freenet-CVS] freenet/src/freenet/node/states/announcement ReplyPending.java, 1.13, 1.14 NewAnnouncement.java, 1.17, 1.18

Update of /cvsroot/freenet/freenet/src/freenet/node/states/announcement In directory sc8-pr-cvs1:/tmp/cvs-serv17945/src/freenet/node/states/announcement Modified Files: ReplyPending.java NewAnnouncement.java Log Message: get rid of some yellowies Index: ReplyPending.java

[freenet-CVS] freenet/src/freenet/node SmartFailureTable.java, NONE, 1.1

Update of /cvsroot/freenet/freenet/src/freenet/node In directory sc8-pr-cvs1:/tmp/cvs-serv23686/src/freenet/node Added Files: SmartFailureTable.java Log Message: initial commit --- NEW FILE: SmartFailureTable.java --- package freenet.node; import freenet.Core; import freenet.Key;

[freenet-CVS] freenet/src/freenet/node SmartFailureTable.java, 1.1, 1.2 FailureTable.java, 1.11, 1.12

Update of /cvsroot/freenet/freenet/src/freenet/node In directory sc8-pr-cvs1:/tmp/cvs-serv25916/src/freenet/node Modified Files: SmartFailureTable.java FailureTable.java Log Message: initial commit Index: SmartFailureTable.java

[freenet-CVS] freenet/src/freenet/node SmartFailureTable.java, 1.2, 1.3 FailureTable.java, 1.12, 1.13

Update of /cvsroot/freenet/freenet/src/freenet/node In directory sc8-pr-cvs1:/tmp/cvs-serv28319/src/freenet/node Modified Files: SmartFailureTable.java FailureTable.java Log Message: have fun toad :) Index: SmartFailureTable.java

[freenet-dev] xsl in fproxy

Can anyone familiar with xsl list the differences between filtering html for anonimity-compromising content and filtering xsl transformations? If an xml file is filtered agains the current rules (no off-freenet links, no actions) and its corresponding xsl is made sure not to contain any such

[freenet-dev] null stream from buffer is back! ;-)

To all fans of this eternal error message, here's some more: (build 6273) Oct 22, 2003 9:55:17 PM (freenet.node.Node, QThread-174, ERROR): Error while receiving message freenet.Message: Ac cepted @[EMAIL PROTECTED] for tcp/connection: 55930209.210.55.3:11902,freenet.transport.tcpConnec [EMAIL

[freenet-dev] cache broken too

lets not forget this other favorite... Oct 22, 2003 10:32:31 PM (freenet.node.states.request.TransferReply, QThread-260, ERROR): Send failed, cache broke n! for freenet.node.states.request.TransferReply: key=92b8d318833e6d7e5e8a8d18388dbbe9ba94df00140302, hopsToLive=1 3, id=bfac2582bdef4813,

[freenet-dev] exception in 6264

java.lang.NullPointerException at freenet.interfaces.BaseLocalNIOInterface.intAddress(BaseLocalNIOInterface.java:37) at freenet.interfaces.BaseLocalNIOInterface.hostAllowed(BaseLocalNIOInterface.java:189) at

[freenet-dev] using reflection in fred

The state chain code uses the reflection api heavily. Official tutorials from Sun recommend reflection to be used only as a last resort, i.e. if the problem cannot be solved any other way. RTTI in win32 adds tons of overhead. insert other examples here Is anyone out there 100% positive that

[freenet-dev] incoming at port -2 with build 6235

sorry for the html, images were removed. OCM lists some connections as incoming at port -2, -1... -1 208.39.42.23:35634 0 2,493 Bytes - None0 s 1 s 35713 207.32.9.50:11975 366 299 KiB - 294 KiB 0 s 6:46 -2

  1   2   >