[freenet-dev] Current uservoice top 5
Matthew Toseland schrieb: > 1. Release the 20 nodes barrier (206 votes) > > As I have mentioned IMHO this is a straightforward plea for more performance. > > 2. One GUI for all. (155 votes) > > This is usability, particularly bundling more functionality. VIVE LA Freetalk! > > 3. Add a 'pause' feature. (131 votes) > > Remarkably high ranking, I wonder what proportion of our users use online > games? > > 4. Implement reinsert on demand. (79 votes) > > This is IMHO about data persistence. > > 5. Use port 80,443,53,1863 for communication. (74 votes) > > I have no idea how this got into the top 5! Any ideas? People trying to run > nodes at work perhaps? The last one may be because of censorship fearing. I have heard at least 1 report about an ISP blocking almost all UDP traffic, allowing only port 53. The user was forced to use port 53(udp) to be able to use freenet. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 315 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090504/67b6ea2c/attachment.pgp>
[freenet-dev] Current uservoice top 5
Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland: > 5. Use port 80,443,53,1863 for communication. (74 votes) > > I have no idea how this got into the top 5! Any ideas? People trying to run > nodes at work perhaps? Maybe not wanting the provider to be able to just shut down nonstandard ports and block freenet that way. ISPs can block freenet ports, but shouldn't really block 80 - at least for outgoing connections. Maybe running it on a server. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090504/b908e4ad/attachment.pgp>
[freenet-dev] Current uservoice top 5
Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland: > 3. Add a 'pause' feature. (131 votes) > > Remarkably high ranking, I wonder what proportion of our users use online > games? Or with other filesharing services (short lived torrents, downloading in Gnutella) or with graphics editing or video editing or just plain compiling the new packages or haggling with a completely overloaded E-Mail program... Uhm, these were most of my reasons for wanting a pause feature :) It would be nicest if using the pause feature would also reduce the memory footprint... but most memory will be swapped out if it isn't used, so the pause feature alone should suffice for freeing memory :) Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090504/fe147250/attachment.pgp>
[freenet-dev] Current uservoice top 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > 5. Use port 80,443,53,1863 for communication. (74 votes) > > I have no idea how this got into the top 5! Any ideas? People trying to run > nodes at work perhaps? University students who want to connect their node in uni with one that runs somewhere home... ??? - Volodya - -- http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal http://www.freedomporn.org/ Freedom Porn, anarchist and activist smut "None of us are free until all of us are free."~ Mihail Bakunin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn/OjAACgkQuWy2EFICg+2x0QCfUW0DondcaxHykZHCpCuoBMFa yCAAoOtfe5h5a74qxW5VV4sCa7SFTEYr =UFDS -END PGP SIGNATURE-
[freenet-dev] name for this plugin
dear all i'm coding a distributed indexing service as my gsoc project... problem is, i don't know what to name it. current ideas: - interdex - sounds like a corporation - distrex - sounds like "distress" - distridex - sounds like an insecticide - wydex - sounds like a stock - codex - could be confused with codecs free feel to spam me with as many as you can think of; atm i am dry and needing ideas. if i can't think up a name i will consider naming it ? (hexagram for gathering together); feel free to consider this a threat :p thanks, X
[freenet-dev] Can we implement Bloom filter sharing quickly???
On Saturday 02 May 2009 01:23:23 Evan Daniel wrote: > On Fri, May 1, 2009 at 7:59 PM, Matthew Toseland > wrote: > > On Saturday 02 May 2009 00:53:27 Evan Daniel wrote: > >> On Fri, May 1, 2009 at 7:01 PM, Matthew Toseland > >> wrote: > >> > On Friday 01 May 2009 22:43:50 Robert Hailey wrote: > >> >> > >> >> On May 1, 2009, at 3:46 PM, Evan Daniel wrote: > >> >> > >> >> > Yes, that's a question worth considering. ?There are both performance > >> >> > and security issues involved, I think. ?Note that the partition could > >> >> > be a set of contiguous regions (allowing performance optimization > >> >> > around which piece of the keyspace you send info about), but it could > >> >> > just as easily be determined by a hash function instead. > >> >> > > >> >> > You still check the same number of filters overall -- one per peer. > >> >> > The difference is that for some peers you may have a partial filter > >> >> > set, and therefore sometimes check their filters, instead of deciding > >> >> > you don't have the memory for that peer's filter and never checking > >> >> > it. > >> >> > >> >> Maybe if we partition it we can also get a free datastore histogram on > >> >> the stats page. > >> > > >> > No, we cannot divide by actual keyspace, the keys must be hashed first, or > > the > >> > middle bloom filter will be far too big. > >> > >> Well, you could partition by actual keyspace as long as the partitions > >> are (approximately) equal in population rather than fraction of the > >> keyspace they cover. ?Doing that is only mildly nontrivial, and gives > >> you a histogram with variable-width bars, but still an accurate > >> histogram. ?Each bar would cover the same area; tall and skinny near > >> the node's location, wide and short away from it. > > > > And if the distribution was ever to change ... it's not mildly nontrivial > > IMHO. > > > > Anyway, the first version should simply use the existing filters, to make > > things easy. > > You have to recompute the bloom filter occasionally regardless, > otherwise the counters eventually all saturate. If the distribution > changes enough to be problematic, you rebalance the filters. Fair point. > > If you're willing to be slightly inefficient, you can avoid > recomputing all the filters. When one filter starts getting full, you > split its portion of the keyspace in half and create a pair to take > its place. On average your filters will only be 3/4 full or so, but > you reduce the computational load (though probably not the disk load? > hmm...) Maybe. > > Or you could just partition the keyspace by hashing and trust that > equal size partitions will have equal populations. This may be better and is certainly easier. > > Evan Daniel -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090504/800efeed/attachment.pgp>
[freenet-dev] Current uservoice top 5
1. Release the 20 nodes barrier (206 votes) As I have mentioned IMHO this is a straightforward plea for more performance. 2. One GUI for all. (155 votes) This is usability, particularly bundling more functionality. VIVE LA Freetalk! 3. Add a 'pause' feature. (131 votes) Remarkably high ranking, I wonder what proportion of our users use online games? 4. Implement reinsert on demand. (79 votes) This is IMHO about data persistence. 5. Use port 80,443,53,1863 for communication. (74 votes) I have no idea how this got into the top 5! Any ideas? People trying to run nodes at work perhaps? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090504/7fbddc90/attachment.pgp>
[freenet-dev] Current uservoice top 5
On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland wrote: > 1. Release the 20 nodes barrier (206 votes) > > As I have mentioned IMHO this is a straightforward plea for more performance. I'll reiterate a point I've made before. While this represents a simple plea for performance, I don't think it's an irrational one -- that is, I think the overall network performance is hampered by having all nodes have the same number of connections. Because all connections use similar amounts of bandwidth, the network speed is limited by the slower nodes. This is true regardless of the absolute number of connections; raising the maximum for fast nodes should have a very similar effect to lowering it for slow nodes. What matters is that slow nodes have fewer connections than fast nodes. For example, the max allowed connections (and default setting) could be 1 connection per 2KiB/s output bandwidth, but never more than 20 or less than 15. Those numbers are based on some (very limited) testing I've done -- if I reduce the allowed bw, that is the approximate number of connections required to make full use of it. Reducing the number of connections for slow nodes has some additional benefits. First, my limited testing shows a slight increase in payload % at low bw limits as a result of reducing the connection count (there is some per-connection network overhead). Second, bloom filter sharing represents a per-connection overhead (mostly in the initial transfer -- updates are low bw, as discussed). If (when?) implemented, it will represent a smaller total overhead with fewer connections than with more. Presumably, the greatest impact is on slower nodes. On the other hand, too few connections may make various attacks easier. I have no idea how strong an effect this is. However, a node that has too many connections (ie insufficient bw to use them all fully) may show burstier behavior and thus be more susceptible to traffic analysis. In addition, fewer connections means a larger network diameter on average, which may have an impact on routing. Lower degree also means that the node has fewer neighbor bloom filters to check, which means that a request is compared against fewer stores during its traversal of the network. I'm intentionally suggesting a small change -- it's less likely to cause major problems. By keeping the ratio between slow nodes (15 connections) and fast nodes (20 connections) modest, the potential for reliance on ubernodes is kept minimal. (Similarly, if you want to raise the 20 connections limit instead of lower it, I think it should only be increased slightly.) And finally: I have done some testing on this proposed change. At first glance, it looks like it doesn't hurt and may help. However, I have not done enough testing to be able to say anything with confidence. I'm not suggesting to implement this change immediately; rather, I'm saying that *any* change like this should see some real-world testing before implementation, and that reducing the defaults for slow nodes is as worthy of consideration and testing as raising it for fast nodes. Also: do we have any idea what the distribution of available node bandwidth looks like? Evan Daniel
[freenet-dev] Current uservoice top 5
1. Release the 20 nodes barrier (206 votes) As I have mentioned IMHO this is a straightforward plea for more performance. 2. One GUI for all. (155 votes) This is usability, particularly bundling more functionality. VIVE LA Freetalk! 3. Add a 'pause' feature. (131 votes) Remarkably high ranking, I wonder what proportion of our users use online games? 4. Implement reinsert on demand. (79 votes) This is IMHO about data persistence. 5. Use port 80,443,53,1863 for communication. (74 votes) I have no idea how this got into the top 5! Any ideas? People trying to run nodes at work perhaps? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Can we implement Bloom filter sharing quickly???
On Saturday 02 May 2009 01:23:23 Evan Daniel wrote: On Fri, May 1, 2009 at 7:59 PM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Saturday 02 May 2009 00:53:27 Evan Daniel wrote: On Fri, May 1, 2009 at 7:01 PM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Friday 01 May 2009 22:43:50 Robert Hailey wrote: On May 1, 2009, at 3:46 PM, Evan Daniel wrote: Yes, that's a question worth considering. There are both performance and security issues involved, I think. Note that the partition could be a set of contiguous regions (allowing performance optimization around which piece of the keyspace you send info about), but it could just as easily be determined by a hash function instead. You still check the same number of filters overall -- one per peer. The difference is that for some peers you may have a partial filter set, and therefore sometimes check their filters, instead of deciding you don't have the memory for that peer's filter and never checking it. Maybe if we partition it we can also get a free datastore histogram on the stats page. No, we cannot divide by actual keyspace, the keys must be hashed first, or the middle bloom filter will be far too big. Well, you could partition by actual keyspace as long as the partitions are (approximately) equal in population rather than fraction of the keyspace they cover. Doing that is only mildly nontrivial, and gives you a histogram with variable-width bars, but still an accurate histogram. Each bar would cover the same area; tall and skinny near the node's location, wide and short away from it. And if the distribution was ever to change ... it's not mildly nontrivial IMHO. Anyway, the first version should simply use the existing filters, to make things easy. You have to recompute the bloom filter occasionally regardless, otherwise the counters eventually all saturate. If the distribution changes enough to be problematic, you rebalance the filters. Fair point. If you're willing to be slightly inefficient, you can avoid recomputing all the filters. When one filter starts getting full, you split its portion of the keyspace in half and create a pair to take its place. On average your filters will only be 3/4 full or so, but you reduce the computational load (though probably not the disk load? hmm...) Maybe. Or you could just partition the keyspace by hashing and trust that equal size partitions will have equal populations. This may be better and is certainly easier. Evan Daniel signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] name for this plugin
dear all i'm coding a distributed indexing service as my gsoc project... problem is, i don't know what to name it. current ideas: - interdex - sounds like a corporation - distrex - sounds like distress - distridex - sounds like an insecticide - wydex - sounds like a stock - codex - could be confused with codecs free feel to spam me with as many as you can think of; atm i am dry and needing ideas. if i can't think up a name i will consider naming it ䷬ (hexagram for gathering together); feel free to consider this a threat :p thanks, X ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Current uservoice top 5
On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: 1. Release the 20 nodes barrier (206 votes) As I have mentioned IMHO this is a straightforward plea for more performance. I'll reiterate a point I've made before. While this represents a simple plea for performance, I don't think it's an irrational one -- that is, I think the overall network performance is hampered by having all nodes have the same number of connections. Because all connections use similar amounts of bandwidth, the network speed is limited by the slower nodes. This is true regardless of the absolute number of connections; raising the maximum for fast nodes should have a very similar effect to lowering it for slow nodes. What matters is that slow nodes have fewer connections than fast nodes. For example, the max allowed connections (and default setting) could be 1 connection per 2KiB/s output bandwidth, but never more than 20 or less than 15. Those numbers are based on some (very limited) testing I've done -- if I reduce the allowed bw, that is the approximate number of connections required to make full use of it. Reducing the number of connections for slow nodes has some additional benefits. First, my limited testing shows a slight increase in payload % at low bw limits as a result of reducing the connection count (there is some per-connection network overhead). Second, bloom filter sharing represents a per-connection overhead (mostly in the initial transfer -- updates are low bw, as discussed). If (when?) implemented, it will represent a smaller total overhead with fewer connections than with more. Presumably, the greatest impact is on slower nodes. On the other hand, too few connections may make various attacks easier. I have no idea how strong an effect this is. However, a node that has too many connections (ie insufficient bw to use them all fully) may show burstier behavior and thus be more susceptible to traffic analysis. In addition, fewer connections means a larger network diameter on average, which may have an impact on routing. Lower degree also means that the node has fewer neighbor bloom filters to check, which means that a request is compared against fewer stores during its traversal of the network. I'm intentionally suggesting a small change -- it's less likely to cause major problems. By keeping the ratio between slow nodes (15 connections) and fast nodes (20 connections) modest, the potential for reliance on ubernodes is kept minimal. (Similarly, if you want to raise the 20 connections limit instead of lower it, I think it should only be increased slightly.) And finally: I have done some testing on this proposed change. At first glance, it looks like it doesn't hurt and may help. However, I have not done enough testing to be able to say anything with confidence. I'm not suggesting to implement this change immediately; rather, I'm saying that *any* change like this should see some real-world testing before implementation, and that reducing the defaults for slow nodes is as worthy of consideration and testing as raising it for fast nodes. Also: do we have any idea what the distribution of available node bandwidth looks like? Evan Daniel ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Rants against ffe38b43b83b28323075fcde898fad4a3dc8df3f
commit ffe38b43b83b28323075fcde898fad4a3dc8df3f Author: platy mpb...@gmail.com Date: Fri May 1 01:45:09 2009 +0100 Added a new plugin Http interface with support for response headers ### The idea was to make plugins use Exceptions to send headers back to Toadlets; Why is that interface necessary? What kind of headers do you want to exchange with the client? NextGen$ signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Current uservoice top 5
Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland: 3. Add a 'pause' feature. (131 votes) Remarkably high ranking, I wonder what proportion of our users use online games? Or with other filesharing services (short lived torrents, downloading in Gnutella) or with graphics editing or video editing or just plain compiling the new packages or haggling with a completely overloaded E-Mail program... Uhm, these were most of my reasons for wanting a pause feature :) It would be nicest if using the pause feature would also reduce the memory footprint... but most memory will be swapped out if it isn't used, so the pause feature alone should suffice for freeing memory :) Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Current uservoice top 5
Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland: 5. Use port 80,443,53,1863 for communication. (74 votes) I have no idea how this got into the top 5! Any ideas? People trying to run nodes at work perhaps? Maybe not wanting the provider to be able to just shut down nonstandard ports and block freenet that way. ISPs can block freenet ports, but shouldn't really block 80 - at least for outgoing connections. Maybe running it on a server. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Current uservoice top 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 5. Use port 80,443,53,1863 for communication. (74 votes) I have no idea how this got into the top 5! Any ideas? People trying to run nodes at work perhaps? University students who want to connect their node in uni with one that runs somewhere home... ??? - Volodya - -- http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal http://www.freedomporn.org/ Freedom Porn, anarchist and activist smut None of us are free until all of us are free.~ Mihail Bakunin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn/OjAACgkQuWy2EFICg+2x0QCfUW0DondcaxHykZHCpCuoBMFa yCAAoOtfe5h5a74qxW5VV4sCa7SFTEYr =UFDS -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Current uservoice top 5
Matthew Toseland schrieb: 1. Release the 20 nodes barrier (206 votes) As I have mentioned IMHO this is a straightforward plea for more performance. 2. One GUI for all. (155 votes) This is usability, particularly bundling more functionality. VIVE LA Freetalk! 3. Add a 'pause' feature. (131 votes) Remarkably high ranking, I wonder what proportion of our users use online games? 4. Implement reinsert on demand. (79 votes) This is IMHO about data persistence. 5. Use port 80,443,53,1863 for communication. (74 votes) I have no idea how this got into the top 5! Any ideas? People trying to run nodes at work perhaps? The last one may be because of censorship fearing. I have heard at least 1 report about an ISP blocking almost all UDP traffic, allowing only port 53. The user was forced to use port 53(udp) to be able to use freenet. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Current uservoice top 5
On Monday 04 May 2009 17:29:51 Evan Daniel wrote: On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: 1. Release the 20 nodes barrier (206 votes) As I have mentioned IMHO this is a straightforward plea for more performance. I'll reiterate a point I've made before. While this represents a simple plea for performance, I don't think it's an irrational one -- that is, I think the overall network performance is hampered by having all nodes have the same number of connections. Because all connections use similar amounts of bandwidth, the network speed is limited by the slower nodes. This is true regardless of the absolute number of connections; raising the maximum for fast nodes should have a very similar effect to lowering it for slow nodes. What matters is that slow nodes have fewer connections than fast nodes. For example, the max allowed connections (and default setting) could be 1 connection per 2KiB/s output bandwidth, but never more than 20 or less than 15. What would the point be? Don't we need a significant range for it to make much difference? Those numbers are based on some (very limited) testing I've done -- if I reduce the allowed bw, that is the approximate number of connections required to make full use of it. Reducing the number of connections for slow nodes has some additional benefits. First, my limited testing shows a slight increase in payload % at low bw limits as a result of reducing the connection count (there is some per-connection network overhead). True. Second, bloom filter sharing represents a per-connection overhead (mostly in the initial transfer -- updates are low bw, as discussed). If (when?) implemented, it will represent a smaller total overhead with fewer connections than with more. Presumably, the greatest impact is on slower nodes. Really it's determined by churn, isn't it? Or by any heuristic artificial limits we impose... On the other hand, too few connections may make various attacks easier. I have no idea how strong an effect this is. However, a node that has too many connections (ie insufficient bw to use them all fully) may show burstier behavior and thus be more susceptible to traffic analysis. Yes, definitely true with our current padding algorithms. In addition, fewer connections means a larger network diameter on average, which may have an impact on routing. Lower degree also means that the node has fewer neighbor bloom filters to check, which means that a request is compared against fewer stores during its traversal of the network. True. I'm intentionally suggesting a small change -- it's less likely to cause major problems. By keeping the ratio between slow nodes (15 connections) and fast nodes (20 connections) modest, the potential for reliance on ubernodes is kept minimal. (Similarly, if you want to raise the 20 connections limit instead of lower it, I think it should only be increased slightly.) Why? I don't see the point unless the upper bound is significantly higher than the lower bound: any improvement won't be measurable. And finally: I have done some testing on this proposed change. At first glance, it looks like it doesn't hurt and may help. However, I have not done enough testing to be able to say anything with confidence. I'm not suggesting to implement this change immediately; rather, I'm saying that *any* change like this should see some real-world testing before implementation, and that reducing the defaults for slow nodes is as worthy of consideration and testing as raising it for fast nodes. We did try this (with a minimum of 10 connections), and it seemed that slow nodes with only 10 connections were significantly slower. However, this was not based on widespread testing. My worry is that slow nodes with few connections will be *too* slow, and the network will marginalise them. But it's a tradeoff between slightly more efficiency, fewer routes to choose from, and fewer nodes sending requests... Also: do we have any idea what the distribution of available node bandwidth looks like? It would be great, wouldn't it? Maybe a survey? What questions should we ask? Evan Daniel signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] 9645c37: Fix logging.
Please don't do this.
Closer is for closing the streams _silently_.
(most often in the finally{} block when error have occurred already/expected)
If you want logging, you should call .close() directly.
commit 9645c379de05e4f884ac3c1e2ef616884232963c
Author: xor x...@freenetproject.org
Date: Mon May 4 20:13:04 2009 +0200
Fix logging.
diff --git a/src/freenet/support/io/Closer.java
b/src/freenet/support/io/Closer.java
index 1e7a532..6899e63 100644
--- a/src/freenet/support/io/Closer.java
+++ b/src/freenet/support/io/Closer.java
@@ -46,6 +46,7 @@ public class Closer {
try {
closable.close();
} catch (IOException e) {
+ Logger.error(Closer.class, Error
during close()., e);
}
}
}
@@ -59,7 +60,7 @@ public class Closer {
try {
bucket.free();
} catch(RuntimeException e) {
- Logger.error(bucket, Error during free().);
+ Logger.error(Closer.class, Error
during free()., e);
}
}
}
@@ -75,6 +76,7 @@ public class Closer {
try {
zipFile.close();
} catch (IOException e) {
+ Logger.error(Closer.class, Error
during close()., e);
}
}
}
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Current uservoice top 5
On Mon, May 4, 2009 at 6:15 PM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Monday 04 May 2009 17:29:51 Evan Daniel wrote: On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: 1. Release the 20 nodes barrier (206 votes) As I have mentioned IMHO this is a straightforward plea for more performance. I'll reiterate a point I've made before. While this represents a simple plea for performance, I don't think it's an irrational one -- that is, I think the overall network performance is hampered by having all nodes have the same number of connections. Because all connections use similar amounts of bandwidth, the network speed is limited by the slower nodes. This is true regardless of the absolute number of connections; raising the maximum for fast nodes should have a very similar effect to lowering it for slow nodes. What matters is that slow nodes have fewer connections than fast nodes. For example, the max allowed connections (and default setting) could be 1 connection per 2KiB/s output bandwidth, but never more than 20 or less than 15. What would the point be? Don't we need a significant range for it to make much difference? If the network is in fact limited by the per-connection speed of the slower nodes, and they are in fact a minority of the network, increasing the per-connection bandwidth of the slower nodes by 33% should result in a throughput increase for most of the rest of the network of a similar magnitude. A performance improvement of 10-30% should be easily measurable, and (at the high end of that) noticeable enough to be appreciated by most users. Really, though, the idea would be to use it as a network-wide test. Small tests by a few users are helpful, but not nearly as informative as a network-wide test. Assuming the change produced measurable improvement, it would make sense to explore further changes. For example, changing the range to 15-30, or increasing the per-connection bandwidth requirement, or making the per-connection requirement nonlinear, or some other option. However, security concerns (especially ubernodes) are bigger with more dramatic changes. Those numbers are based on some (very limited) testing I've done -- if I reduce the allowed bw, that is the approximate number of connections required to make full use of it. Reducing the number of connections for slow nodes has some additional benefits. First, my limited testing shows a slight increase in payload % at low bw limits as a result of reducing the connection count (there is some per-connection network overhead). True. To be specific, my anecdotal evidence is that it improves the payload fraction by roughly 3-8%. Second, bloom filter sharing represents a per-connection overhead (mostly in the initial transfer -- updates are low bw, as discussed). If (when?) implemented, it will represent a smaller total overhead with fewer connections than with more. Presumably, the greatest impact is on slower nodes. Really it's determined by churn, isn't it? Or by any heuristic artificial limits we impose... My assumption is that connection duration is well modeled by a per-connection half-life, that is largely independent of the number of connections. The bandwidth used on such filters is proportional to the total churn, so fewer connections means less churn in absolute sense but the same connection half-life. (That is, bloom filter bandwidth usage is proportional to # of connections * per-connection churn rate.) I don't have any evidence for that assumption, though. On the other hand, too few connections may make various attacks easier. I have no idea how strong an effect this is. However, a node that has too many connections (ie insufficient bw to use them all fully) may show burstier behavior and thus be more susceptible to traffic analysis. Yes, definitely true with our current padding algorithms. In addition, fewer connections means a larger network diameter on average, which may have an impact on routing. Lower degree also means that the node has fewer neighbor bloom filters to check, which means that a request is compared against fewer stores during its traversal of the network. True. Do you know how big a problem this would cause? My assumption is that it would be a fairly small effect even on the nodes with fewer connections, and that they would be in the minority. I'm intentionally suggesting a small change -- it's less likely to cause major problems. By keeping the ratio between slow nodes (15 connections) and fast nodes (20 connections) modest, the potential for reliance on ubernodes is kept minimal. (Similarly, if you want to raise the 20 connections limit instead of lower it, I think it should only be increased slightly.) Why? I don't see the point unless the upper bound is significantly higher than the lower bound: any improvement won't be measurable. As above, I would hope that the
