[freenet-dev] usability testing
nds to be usability oriented). > >>>> Exactly. The user is fears the consequences of history leaks and is > >>>> uncertain what he ought to do, and thereby doubts his security and > >>>> privacy using Freenet. > >>> He knows what he needs to do - use a separate browser. Don't we make that > >>> clear? It may be annoying but it is clear, no? > >> It is indeed very clear, but as you say, also damn annoying. If > >> possible, I think we should avoid annoying the user. > > > > Well, any suggestions you may have... afaics the best option on windows is > > to run Chrome in incognito mode, and tell the wizard not to show the > > warning. But in that case we need to warn the user if they ever use another > > browser - and we can't tell the difference between Chrome in incognito mode > > and Chrome not in incognito mode, so I think we should display the warning > > anyway, we just need to rewrite it a bit for the case where we are using > > Chrome in incognito mode: > > > > "You must always use a browser with incognito mode for Freenet! > > > > You are currently using Freenet through Chrome in incognito mode. This > > should be safe. You should always access Freenet using Chrome in incognito > > mode, or through a browser you do not using for normal web browsing. The > > Browse Freenet link on the start menu should use Chrome in incognito mode, > > and so should be safe. Most browsers will work well with Freenet, except > > for Internet Explorer. > > > > Click here to continue." > > > > ??? > > I don't think we should display a warning when the user is browsing in > incognito mode. When the user is not (or we don't know for sure), we > could do it. How could we ever know for sure? If the user opens Freenet using the link and then starts browsing it using regular Chrome, there is no way to detect this, for example. -- 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/20090618/5df84dd9/attachment.pgp>
[freenet-dev] Update to the swedish translation
On Thursday 18 June 2009 16:10:56 Cooo . wrote: > Hi all. > > Here is an minor update to the swedish translation, please commit. > Applied to git rev 1ce0954, thanks. -- 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/20090618/42e34f70/attachment.pgp>
[freenet-dev] Asynchronous image loading
On Thursday 18 June 2009 17:02:06 sashee wrote: > With async image loading,activelinks will be loaded too. > As for the 21 secs. It can be decreased, but only to sacrifice > something else. 21 sec means the client can skip a keepalive, and fail > after the second. Since it's localhost, it's unlikely to fail even 1, > so it can be reduced to 11 sec. If we send keepalives more frequently, > it will consume more resources for all tabs to send them, but it will > reduce further the time needed to detect tab closes. It is easily > configured with constants though. There is no callback on a page being closed? > > sashee > > On Thu, Jun 18, 2009 at 11:33 AM, xor wrote: > > On Wednesday 17 June 2009 16:36:26 sashee wrote: > >> Hello folks! > >> > >> Some days ago, I've talked with nextgens about toadlet > >> continuations(it's asynchronous request processing), and he had a > >> point that when the user opens a site with lots of images, then it > >> needs many connections open for a long time, and it spawns many > >> threads at serverside, which is resource demanding and some OSes don't > >> allow. The browser has a maximum connection limit to the site, but the > >> user can overwrite it. But at the default, firefox opens only 2-3 > >> connections to fetch the images, this way freenet don't start all the > >> fetching, just what is requested. So one problem is that if a user > >> alters the browser's config, then it will result many threads, if not, > >> then freenet can't download all the content simultanously. > >> I think with pushing, I'm working on, can be a solution for both > >> problems. When the page loads, freenet start fetching all the images, > >> and the browser gets the progress with 1 permanent connection. There > >> can be an image eg. "Image is loading...10%" and after some progress > >> change to 20% and so on, and when finishes downloading, it shows or > >> says eg. "Image finished loading, click to display". If it's done, we > >> don't need continuations anymore. Ofc it would need javascript to be > >> enabled. > >> > >> What you think? > > > > I filed a bug on that regarding activelinks, containing one possible way to > > solve it via javascript: > > > > https://bugs.freenetproject.org/view.php?id=3207 > > > > So when you implement it, please also do it for activelinks, as they are > > nice > > to have and could be re-enabled then. > > > > xor -- 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/20090618/51e95c10/attachment.pgp>
[freenet-dev] need graphic design help
On Wednesday 17 June 2009 20:43:19 Caco Patane wrote: > > I think he means that users in "poor" areas usually run pirated versions > > of XP with the included IE6. Many of these installations won't have a > > functional Windows Update because of the "Genuine Advantage" stuff > > Microsoft pushes through it. Wich means that they won't get IE updates > > automatically, and probably won't/can't upgrade manually. > > That's it! But not only poor areas, only companies and laptop users > run genuine software. Brand computers (Dell, IBM, etc) are only > purchased by multinational corporations. I used an original copy of > windows for a work in a big corp, not even un goverment offices (kinda > fun). I think that the same scenarios goes for all latin america... > Venezuela, Bolivia and Cuba are in "delicate" positions regarding > freedom of speech. Chavez already closed a TV channel =D > > For the PNG thing, we can use the PNG with transparent background and > in the tag include: > > > > No new image is needed, those javascripts "fix" it. IMHO that is a good idea if it is not disruptive. Can you deal with it? -- 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/20090618/a72348b0/attachment.pgp>
[freenet-dev] About the website
On Wednesday 17 June 2009 20:09:53 3BUIb3S50i 3BUIb3S50i wrote: > Can you make a link to another languages? (Like french wiki.) See > https://bugs.freenetproject.org/view.php?id=2915 If people are interested in translating the website we can serve different content for different languages. So far we have a partial german translation and one other which is *really* partial. Both are out of date. > > On Wed, Jun 17, 2009 at 1:57 PM, Matthew Toseland amphibian.dyndns.org > > wrote: > > > On Wednesday 17 June 2009 07:40:18 Arne Babenhauserheide wrote: > > > Am Mittwoch, 17. Juni 2009 05:26:25 schrieb Luke771: > > > > Browse and publish 'freesites' (Freenet-hosted websites) > > > > > > This one sounds very nice to me. It gets people into the freenet-speech > > and at > > > the same time tells them why we use it (what's the difference between a > > > freesite and a normal website). > > > > Currently it is: > > > > Freenet is free software which lets you anonymously share files, browse and > > publish "freesites" (web sites accessible only through Freenet) and chat on > > forums, without fear of censorship. Users are anonymous, and Freenet is > > entirely decentralised. Without anonymity there can never be true freedom of > > speech, and without decentralisation the network would be vulnerable to > > attack. -- 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/20090618/aed3f3f9/attachment.pgp>
[freenet-dev] need graphic design help
Find attached 3 screenshots: freenet-website-ie6.png - The way I see the site without any change freenet-website-ie6-pngfix.png - The way I see the site with the PNG fix in IE6 freenet-website-ff-pngfix.png - The way I see the site with the PNG fix in FF The fix does not work very well for transparent backgrounds (an extra-padding seems to be applied) but it's less ugly than withouth the fix. Both files needed to fix are 997 bytes, plus 94 characters in the HTML. If somebody is worried about a bigger HTML: both HTML and CSS code is full of redundant whitespaces and can be cleaned. Users not using IE6 will not download both files required for the fix. Let me know if you want to apply the fix or provide more info about it. Saludos, Caco_Patane On Thu, Jun 18, 2009 at 7:27 PM, Matthew Toseland wrote: >> For the PNG thing, we can use the PNG with transparent background and >> in the tag include: >> >> >> >> No new image is needed, those javascripts "fix" it. > > IMHO that is a good idea if it is not disruptive. Can you deal with it? -- next part -- A non-text attachment was scrubbed... Name: freenet-website-ie6.png Type: image/png Size: 67276 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090618/9d8a4572/attachment.png> -- next part -- A non-text attachment was scrubbed... Name: freenet-website-ie6-pngfix.png Type: image/png Size: 67547 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090618/9d8a4572/attachment-0001.png> -- next part -- A non-text attachment was scrubbed... Name: freenet-website-ff-pngfix.png Type: image/png Size: 57114 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090618/9d8a4572/attachment-0002.png>
[freenet-dev] FCP questions
I'm trying to test out SSK inserts with FCP, and running into problems. First, the Disconnect command does not work: Disconnect EndMessage ProtocolError ExtraDescription=Unknown message name Disconnect Fatal=false CodeDescription=Don't know what to do with message Code=7 EndMessage Second, DDA isn't working: TestDDARequest Directory=/data/freenet/ WantReadDirectory=true WantWriteDirectory=false EndMessage TestDDAReply ReadFilename=/data/freenet/DDACheck-2801570529831049194.tmp Directory=/data/freenet EndMessage TestDDAResponse Directory=/data/freenet/ ReadContent=[stuff read from file indicated above] EndMessage TestDDAComplete ReadDirectoryAllowed=false Directory=/data/freenet EndMessage Third, if I didn't want to use DDA to insert my data, how would I do that? The documentation on ClientPut doesn't say how to actually send data in the direct mode. Evan Daniel
[freenet-dev] Variable opennet connections: moving forward
On Thu, Jun 18, 2009 at 8:00 PM, Matthew Toseland wrote: > Are you doing more testing? > > On Saturday 13 June 2009 19:05:36 Evan Daniel wrote: >> On Sat, Jun 13, 2009 at 1:08 PM, Matthew >> Toseland wrote: >> > Now that 0.7.5 has shipped, we can start making disruptive changes again >> > in a few days. The number one item on freenet.uservoice.com has been for >> > some time to allow more opennet peers for fast nodes. We have discussed >> > this in the past, and the conclusions which I agree with and some others >> > do: >> > - This is feasible. >> > - It will not seriously break routing. >> > - Reducing the number of connections on slow nodes may actually be a gain >> > in security, by increasing opportunities for coalescing. It will improve >> > payload percentages, improve average transfer rates, let slow nodes accept >> > more requests from each connection, and should improve overall performance. >> > - The network should be less impacted by the speed of the slower nodes. >> > - But we have tested using fewer connections on slow nodes in the past and >> > had anecdotal evidence that it is slower. We need to evaluate it more >> > rigorously somehow. >> > - Increasing the number of peers allowed for fast opennet nodes, within >> > reason, should not have a severe security impact. It should improve >> > routing (by a smaller network diameter). It will of course allow fast >> > nodes to contribute more to the network. We do need to be careful to avoid >> > overreliance on ubernodes (hence an upper limit of maybe 50 peers). >> > - Routing security: FOAF routing allows you to capture most of the traffic >> > from a node already, the only thing stopping this is the 30%-to-one-peer >> > limit. >> > - Coalescing security: Increasing the number of peers without increasing >> > the bandwidth usage does increase vulnerability to traffic analysis by >> > doing less coalescing. On the other hand, this is not a problem if the >> > bandwidth usage scales with the number of nodes. >> > >> > How can we move forward? We need some reliable test results on whether a >> > 10KB/sec node is better off with 10 peers or with 20 peers. I think it's a >> > fair assumption for faster nodes. Suggestions? >> >> I haven't tested at numbers that low. ?At 15KiB/s, the stats page >> suggests your slightly better off with 12-15 peers than 20. ?I saw no >> subjective difference in browsing speed either way. >> >> I'm happy to do some testing here, if you tell me what data you want >> me to collect. ?More testers would obviously be good. >> >> > >> > We also need to set some arbitrary parameters. There is an argument for >> > linearity, to avoid penalising nodes with different bandwidth levels, but >> > nodes with more peers and the same amount of bandwidth per peer are likely >> > to be favoured by opennet anyway... Non-linearity, in the sense of having >> > a lower threshold and an upper threshold and linearly add peers between >> > them but not necessarily consistently with the lower threshold, would mean >> > fewer nodes with lots of peers, and might achieve better results? E.g. >> > >> > 10 peers at 10KB/sec ... 20 peers at 20KB/sec (1 per KB/sec) >> > 20 peers at 20KB/sec ... 50 peers at 80KB/sec (1 per 3KB/sec) >> >> I wouldn't go as low as 10 peers, simply because I haven't tested it. >> Other than that, those seem perfectly sensible to me. >> >> We should also watch for excessive cpu usage. ?If there's lots of bw >> available, we'd want to have just enough connections to not quite >> limit on available cpu power. ?Of course, I don't really know how many >> connections / how much bw it is before that becomes a concern. >> >> Evan Daniel > I'd been running the Spider, and trying to get a complete run out of it in order to provide a full set of bug reports. Unfortunately, after spidering over 100k keys (representing over a week of runtime), the .dbs file became unrecoverably corrupted, and it won't write index files. I had started rerunning it; I've since paused that and started taking data on connections. I've got a little data so far at 12KiB/s limit, 10 and 12 peers. Basically, I don't see a difference between 10 and 12 peers. Both produce reasonable performance numbers. My node has 2 darknet peers, remainder opennet. I'm not using the node much during these tests; it has a few MiB of downloads queued that aren't making progress (old files that have probably dropped off). Evan Daniel 12 peers, 12 KiB/s limit # bwlimitDelayTime: 91ms # nodeAveragePingTime: 408ms # darknetSizeEstimateSession: 0 nodes # opennetSizeEstimateSession: 63 nodes # nodeUptime: 1h37m # Connected: 10 # Backed off: 2 # Input Rate: 2.54 KiB/s (of 60.0 KiB/s) # Output Rate: 12.9 KiB/s (of 12.0 KiB/s) # Total Input: 31.3 MiB (5.5 KiB/s average) # Total Output: 47.5 MiB (8.34 KiB/s average) # Payload Output: 32.6 MiB (5.73 KiB/sec)(68%) 1469Output bandwidth liability 18 >SUB_MAX_PING_TIME Success rates Group P(su
Re: [freenet-dev] Can we implement Bloom filter sharing quickly???
On Fri, May 01, 2009 at 03:58:27PM -0400, Evan Daniel wrote: > On Fri, May 1, 2009 at 3:37 PM, Robert Hailey > wrote: > > > > On May 1, 2009, at 9:35 AM, Matthew Toseland wrote: > > > > IMPLEMENTING IT: > > Main tasks: > > - Converting our datastore indexes into a compact, slightly more lossy, > > 1-bit > > filter. (Easy) > > - Creating a snapshot once an hour, and keeping for some period (1 week?). > > (Easy) > > - Creating an efficient binary diff format for hour-to-hour diffs, and > > keeping > > them. (Moderate) > > > > This might actually be quite hard as an efficient bloom filter will scatter > > (even a few) updates all over the filter. > > Actually, it's not hard at all. > > The naive version is to observe that a tiny fraction of the bits in > the filter changed, and just record the location of each bit that > changed. At 0.24 writes per second, you'll get on average 0.24*3600*2 > keys changed per hour (each write represents 1 add and 1 delete), or > 0.24*3600*2*16 counters changed per hour. Unless I'm mistaken, > changing a counter in the counting bloom filter has ~ 50% probability > of changing the bit in the compressed non-counting version. So that > means 0.24*3600*2*16*0.5=13824 bits changed per hour. > > The address of a bit can be represented in 32 bits trivially (for > bloom filters < 512MiB in size), so the 1-hour diff should consume > 13824*32/8=55296 bytes. That represents 15.36 bytes/s of traffic for > each peer, or 307.2B/s across 20 peers. > > That encoding isn't terribly efficient. More efficient is to sort the > addresses and compute the deltas. (So if bits 19, 7, and 34 changed, > I send the numbers 7, 12, 15.) Those deltas should follow a geometric > distribution with mean (number of bits changed) / (size of filter). > It's easy to build an arithmetic coding for that data that will > achieve near-perfect compression (see > http://en.wikipedia.org/wiki/Arithmetic_coding for example). My BOTE > estimate using toad's 84MiB filter it would compress at 14.5 bits per > address (instead of the 30 or 32 you'd get with no compression; gzip > or lzw should be somewhere in between). > > Evan CHUNK SIZE PROBLEM: === Current plans call to split the keyspace up for each datastore, and assign keys to a manageable sized bloom filter for a section of the (hashed) keyspace. These can then be transferred separately, are useful immediately after being transferred, can be juggled in memory, etc. However, we cannot guarantee that the populaion of such a chunk will be small enough for the filter to be effective. Solving this requires either moving the boundaries dynamically (possibly continually), or making the chunks significantly larger than they would need to be in an ideal world. FALSE POSITIVES ISSUES WITH SECOND PHASE: = 23 bits = 0.159 false positives probability (0.00159%). Second phase, we will want to check all of our queued keys against an hourly Bloom filter update. Probably we would do this hourly plus on connect. We simply keep a file containing a list of all the keys we care about, and read it linearly, comparing with the Bloom filters as we go (thanks evanbd). One problem with this is that the false positives ratio applies to each lookup, and since we'd be looking up the entire queue, we could expect a lot of false positives. Only a small fraction of the filter has changed, so most false positives will have already been hit at some point... If we can be sure we have tried all opportunities already, we can safely ignore any hit that is in both the old and new filters, otherwise we will need to keep a list of false positives for the node; this is only consulted when we are about to send a request so it is probably acceptable overhead. Or we can leave it to chance, 23 bits gives 532 false positives out of 1TB queue. HASHES VERSUS BLOOMS: = Curiously enough, we could cut the update traffic by a factor of 4 by sending 64-bit hashes of the new and removed keys, rather than the positions of the changed bits. Even compared to an arithmetic encoding on the positions this cuts it by a factor of 2: ((0.24*3600*2*64)/8)/3600 = 3.84 bytes/sec/peer for the same assumptions as the numbers above. The size in memory, and the size of the initial transfer, are the interesting bits though. Clearly if the hash size is 64 bits, the original transfer would be larger than with bloom filters' 23 bits, even taking into account the chunk size problem. But the hash size only needs to be 16 bits (gives us same false positives as blooms of 23 bits) plus upper bound log2 of the datastore size. So 31 bits per key for a 500GB datastore. Since the data is only updated hourly, we could simply keep a sorted array of the hashed keys in RAM... On the server side we can do something very similar, generating a sorted list and then recording new and removed keys separately and consolidating hourl
[freenet-dev] FCP questions
I'm trying to test out SSK inserts with FCP, and running into problems. First, the Disconnect command does not work: Disconnect EndMessage ProtocolError ExtraDescription=Unknown message name Disconnect Fatal=false CodeDescription=Don't know what to do with message Code=7 EndMessage Second, DDA isn't working: TestDDARequest Directory=/data/freenet/ WantReadDirectory=true WantWriteDirectory=false EndMessage TestDDAReply ReadFilename=/data/freenet/DDACheck-2801570529831049194.tmp Directory=/data/freenet EndMessage TestDDAResponse Directory=/data/freenet/ ReadContent=[stuff read from file indicated above] EndMessage TestDDAComplete ReadDirectoryAllowed=false Directory=/data/freenet EndMessage Third, if I didn't want to use DDA to insert my data, how would I do that? The documentation on ClientPut doesn't say how to actually send data in the direct mode. Evan Daniel ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Asynchronous image loading
With async image loading,activelinks will be loaded too. As for the 21 secs. It can be decreased, but only to sacrifice something else. 21 sec means the client can skip a keepalive, and fail after the second. Since it's localhost, it's unlikely to fail even 1, so it can be reduced to 11 sec. If we send keepalives more frequently, it will consume more resources for all tabs to send them, but it will reduce further the time needed to detect tab closes. It is easily configured with constants though. sashee On Thu, Jun 18, 2009 at 11:33 AM, xor wrote: > On Wednesday 17 June 2009 16:36:26 sashee wrote: >> Hello folks! >> >> Some days ago, I've talked with nextgens about toadlet >> continuations(it's asynchronous request processing), and he had a >> point that when the user opens a site with lots of images, then it >> needs many connections open for a long time, and it spawns many >> threads at serverside, which is resource demanding and some OSes don't >> allow. The browser has a maximum connection limit to the site, but the >> user can overwrite it. But at the default, firefox opens only 2-3 >> connections to fetch the images, this way freenet don't start all the >> fetching, just what is requested. So one problem is that if a user >> alters the browser's config, then it will result many threads, if not, >> then freenet can't download all the content simultanously. >> I think with pushing, I'm working on, can be a solution for both >> problems. When the page loads, freenet start fetching all the images, >> and the browser gets the progress with 1 permanent connection. There >> can be an image eg. "Image is loading...10%" and after some progress >> change to 20% and so on, and when finishes downloading, it shows or >> says eg. "Image finished loading, click to display". If it's done, we >> don't need continuations anymore. Ofc it would need javascript to be >> enabled. >> >> What you think? > > I filed a bug on that regarding activelinks, containing one possible way to > solve it via javascript: > > https://bugs.freenetproject.org/view.php?id=3207 > > So when you implement it, please also do it for activelinks, as they are nice > to have and could be re-enabled then. > > xor > > ___ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
Re: [freenet-dev] Variable opennet connections: moving forward
On Thu, Jun 18, 2009 at 8:00 PM, Matthew Toseland wrote: > Are you doing more testing? > > On Saturday 13 June 2009 19:05:36 Evan Daniel wrote: >> On Sat, Jun 13, 2009 at 1:08 PM, Matthew >> Toseland wrote: >> > Now that 0.7.5 has shipped, we can start making disruptive changes again >> > in a few days. The number one item on freenet.uservoice.com has been for >> > some time to allow more opennet peers for fast nodes. We have discussed >> > this in the past, and the conclusions which I agree with and some others >> > do: >> > - This is feasible. >> > - It will not seriously break routing. >> > - Reducing the number of connections on slow nodes may actually be a gain >> > in security, by increasing opportunities for coalescing. It will improve >> > payload percentages, improve average transfer rates, let slow nodes accept >> > more requests from each connection, and should improve overall performance. >> > - The network should be less impacted by the speed of the slower nodes. >> > - But we have tested using fewer connections on slow nodes in the past and >> > had anecdotal evidence that it is slower. We need to evaluate it more >> > rigorously somehow. >> > - Increasing the number of peers allowed for fast opennet nodes, within >> > reason, should not have a severe security impact. It should improve >> > routing (by a smaller network diameter). It will of course allow fast >> > nodes to contribute more to the network. We do need to be careful to avoid >> > overreliance on ubernodes (hence an upper limit of maybe 50 peers). >> > - Routing security: FOAF routing allows you to capture most of the traffic >> > from a node already, the only thing stopping this is the 30%-to-one-peer >> > limit. >> > - Coalescing security: Increasing the number of peers without increasing >> > the bandwidth usage does increase vulnerability to traffic analysis by >> > doing less coalescing. On the other hand, this is not a problem if the >> > bandwidth usage scales with the number of nodes. >> > >> > How can we move forward? We need some reliable test results on whether a >> > 10KB/sec node is better off with 10 peers or with 20 peers. I think it's a >> > fair assumption for faster nodes. Suggestions? >> >> I haven't tested at numbers that low. At 15KiB/s, the stats page >> suggests your slightly better off with 12-15 peers than 20. I saw no >> subjective difference in browsing speed either way. >> >> I'm happy to do some testing here, if you tell me what data you want >> me to collect. More testers would obviously be good. >> >> > >> > We also need to set some arbitrary parameters. There is an argument for >> > linearity, to avoid penalising nodes with different bandwidth levels, but >> > nodes with more peers and the same amount of bandwidth per peer are likely >> > to be favoured by opennet anyway... Non-linearity, in the sense of having >> > a lower threshold and an upper threshold and linearly add peers between >> > them but not necessarily consistently with the lower threshold, would mean >> > fewer nodes with lots of peers, and might achieve better results? E.g. >> > >> > 10 peers at 10KB/sec ... 20 peers at 20KB/sec (1 per KB/sec) >> > 20 peers at 20KB/sec ... 50 peers at 80KB/sec (1 per 3KB/sec) >> >> I wouldn't go as low as 10 peers, simply because I haven't tested it. >> Other than that, those seem perfectly sensible to me. >> >> We should also watch for excessive cpu usage. If there's lots of bw >> available, we'd want to have just enough connections to not quite >> limit on available cpu power. Of course, I don't really know how many >> connections / how much bw it is before that becomes a concern. >> >> Evan Daniel > I'd been running the Spider, and trying to get a complete run out of it in order to provide a full set of bug reports. Unfortunately, after spidering over 100k keys (representing over a week of runtime), the .dbs file became unrecoverably corrupted, and it won't write index files. I had started rerunning it; I've since paused that and started taking data on connections. I've got a little data so far at 12KiB/s limit, 10 and 12 peers. Basically, I don't see a difference between 10 and 12 peers. Both produce reasonable performance numbers. My node has 2 darknet peers, remainder opennet. I'm not using the node much during these tests; it has a few MiB of downloads queued that aren't making progress (old files that have probably dropped off). Evan Daniel 12 peers, 12 KiB/s limit # bwlimitDelayTime: 91ms # nodeAveragePingTime: 408ms # darknetSizeEstimateSession: 0 nodes # opennetSizeEstimateSession: 63 nodes # nodeUptime: 1h37m # Connected: 10 # Backed off: 2 # Input Rate: 2.54 KiB/s (of 60.0 KiB/s) # Output Rate: 12.9 KiB/s (of 12.0 KiB/s) # Total Input: 31.3 MiB (5.5 KiB/s average) # Total Output: 47.5 MiB (8.34 KiB/s average) # Payload Output: 32.6 MiB (5.73 KiB/sec)(68%) 1469Output bandwidth liability 18 >SUB_MAX_PING_TIME Success rates Group P(su
Re: [freenet-dev] Variable opennet connections: moving forward
Are you doing more testing? On Saturday 13 June 2009 19:05:36 Evan Daniel wrote: > On Sat, Jun 13, 2009 at 1:08 PM, Matthew > Toseland wrote: > > Now that 0.7.5 has shipped, we can start making disruptive changes again in > > a few days. The number one item on freenet.uservoice.com has been for some > > time to allow more opennet peers for fast nodes. We have discussed this in > > the past, and the conclusions which I agree with and some others do: > > - This is feasible. > > - It will not seriously break routing. > > - Reducing the number of connections on slow nodes may actually be a gain > > in security, by increasing opportunities for coalescing. It will improve > > payload percentages, improve average transfer rates, let slow nodes accept > > more requests from each connection, and should improve overall performance. > > - The network should be less impacted by the speed of the slower nodes. > > - But we have tested using fewer connections on slow nodes in the past and > > had anecdotal evidence that it is slower. We need to evaluate it more > > rigorously somehow. > > - Increasing the number of peers allowed for fast opennet nodes, within > > reason, should not have a severe security impact. It should improve routing > > (by a smaller network diameter). It will of course allow fast nodes to > > contribute more to the network. We do need to be careful to avoid > > overreliance on ubernodes (hence an upper limit of maybe 50 peers). > > - Routing security: FOAF routing allows you to capture most of the traffic > > from a node already, the only thing stopping this is the 30%-to-one-peer > > limit. > > - Coalescing security: Increasing the number of peers without increasing > > the bandwidth usage does increase vulnerability to traffic analysis by > > doing less coalescing. On the other hand, this is not a problem if the > > bandwidth usage scales with the number of nodes. > > > > How can we move forward? We need some reliable test results on whether a > > 10KB/sec node is better off with 10 peers or with 20 peers. I think it's a > > fair assumption for faster nodes. Suggestions? > > I haven't tested at numbers that low. At 15KiB/s, the stats page > suggests your slightly better off with 12-15 peers than 20. I saw no > subjective difference in browsing speed either way. > > I'm happy to do some testing here, if you tell me what data you want > me to collect. More testers would obviously be good. > > > > > We also need to set some arbitrary parameters. There is an argument for > > linearity, to avoid penalising nodes with different bandwidth levels, but > > nodes with more peers and the same amount of bandwidth per peer are likely > > to be favoured by opennet anyway... Non-linearity, in the sense of having a > > lower threshold and an upper threshold and linearly add peers between them > > but not necessarily consistently with the lower threshold, would mean fewer > > nodes with lots of peers, and might achieve better results? E.g. > > > > 10 peers at 10KB/sec ... 20 peers at 20KB/sec (1 per KB/sec) > > 20 peers at 20KB/sec ... 50 peers at 80KB/sec (1 per 3KB/sec) > > I wouldn't go as low as 10 peers, simply because I haven't tested it. > Other than that, those seem perfectly sensible to me. > > We should also watch for excessive cpu usage. If there's lots of bw > available, we'd want to have just enough connections to not quite > limit on available cpu power. Of course, I don't really know how many > connections / how much bw it is before that becomes a concern. > > 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] Builds 1219, 1220, 1221 and 1222
On Friday 12 June 2009 20:02:06 Matthew Toseland wrote: > A series of increasingly desperate pre-release builds: > 1219: > - Various translation and wording improvements. > - Much less disk access for inserts when a segment has been completed, and a > fix for a NullPointerException that was causing some site inserts to stall at > 100%. > - Better handling of plugins load failures, sort the dropdown list in > alphabetical order, workaround a Freemail bug so it doesn't get shown on that > list if it is already loaded, class loader fix. > - Reduce the severity of the peers-say-key-is-blown warning. > - Make clean-dropdown the default theme, this has a horizontal menu with > pulldown submenus, saves lots of space, and doesn't jump around when you > mouseover. > - Simple vs advanced flag is now applied globally immediately. > - Tell the user when a file is compressing, and when it is waiting to be > compressed. > - Remove the "je dump" button from the stats page. > - Improve appearance of the confirmation pages for high friends seclevel / > high network seclevel in the wizard. > - Fix a rare bug causing a transfer to stall for over an hour. > - Change some strings to say 0.7.5 not 0.7. Add a new "release version" since > we can't actually change nodeVersion safely. > > 1220: > - Don't tell the user a file is being compressed if it has the dont compress > flag on. > - Change the default fproxy max-size to 2.1MB, workaround bugs in site > insertion code, several sites are like this atm. > - Show the filename on the MIME type warning page. > - Make the peers-say-key-is-blown page even less alarming, basically it is > saying why we can't update at the moment. > - German update, mention incognito mode and Chrome on the separate-browser > warning page at the beginning of the wizard. > > 1221: > - Various changes to the auto-updater to prevent the current deliberate > malicious attack which is causing lots of nodes to say that their peers have > found the revocation key. > > 1222: > - Don't show the progress page if ?forcedownload is set, this causes us to > send a new copy of the data every 2 seconds! > - Fix a NullPointerException preventing startup on some nodes introduced in > 1221. Sorry folks! > FYI, detailed changelog for 1221: 1221: Auto-updater: handling of transfer of revocation certs from peers: - Fix a bug where we would not remove from nodesSayKeyRevoked when the URI isn't parsable. - Only count connected nodes when deciding whether we should suspend update (mightBeRevoked(). - For each peer, track how many revocation failed transfers we've had from a peer since the last disconnection. - Only send UOM announcement talking about revocation certs if we have actually revoked, NOT if we just have a local problem equivalent to revocation. - Separate messages for the auto-update key being blown versus the auto-update key might have been blown or we might have a serious local problem preventing us from knowing whether it has been. In both cases we turn off updating. - Move the revocation key size limits to NodeUpdateManager. Enforce them when decoding a revocation cert. If it is TOO_BIG then it will result in a fatal error and we will treat it as if we had got the revocation cert. Reduce the revocation cert blob max size to 8KB from 4MB. - Don't add to the failed transfers list unless it is an actual failed transfer that might not be the peer's fault. If it's likely to be the peer's fault (e.g. wrong URI), don't worry about it. - Remove from nodesSayKeyRevoked and add to the transferring list just before transfer starts. Don't add to the transferring list at the start of the function; if we asked, will already be in nodesSayKeyRevoked, this is enough; if we don't, it's probably bad anyway. - If a node announces it has the revocation cert and then instantly disconnects before we can ask them, log an error and ignore it. - Bugfix: Remove from the transferring list *before* calling maybeNotRevoked(), when we have a real revocation cert transfer failure. - Tell UpdateOverMandatoryManager when a node is disconnected (and via onRemove, when it is removed too). Fixes memory leaks and necessary for the next change. - Don't start a transfer in UOMAnnounce handler if there is already one running. - Retry a failed transfer for 3 attempts. - For purposes of mightBeRevoked(), ignore any peer which has tried to send the revocation cert and failed transfer more than 3 times. - Don't care about failed transfers in mightBeRevoked, only consider what is waiting for a transfer and what is transferring. Bulk transfer: - Reduce the inter-block timeout on bulk transfers to 30 seconds from 5 minutes. This is still very generous, and it avoids attacks. Dev stuff: - Logging. sdiz toad signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listi
Re: [freenet-dev] usability testing
On Wednesday 17 June 2009 16:26:40 Zero3 wrote: > Matthew Toseland skrev: > > On Wednesday 17 June 2009 09:54:18 Zero3 wrote: > >> Matthew Toseland skrev: > >>> On Tuesday 16 June 2009 21:53:09 Zero3 wrote: > Matthew Toseland skrev: > > On Sunday 14 June 2009 14:24:39 Zero3 wrote: > >> a) On the front page of the website: A "What is Freenet?" teaser > >> linking > >> to the "What is Freenet?" page would be cool. Confusedly started to > >> read > >> the news item instead. (She should have spotted the "News" headline, > >> but > >> I agree on the teaser) > > I think originally the reason for putting news on the main page was > > that a lot of people check back on the website repeatedly, looking for > > new stuff (i.e. news) ?: > > > > I agree we should have some basic explanation and link on the home page > > though ... I am not quite sure whether just copying the first para from > > "What is Freenet" as Dieppe has done is sufficient? > > > > "Freenet is free software which lets you publish and obtain information > > on the Internet without fear of censorship. To achieve this freedom, > > the network is entirely decentralized and publishers and consumers of > > information are anonymous. Without anonymity there can never be true > > freedom of speech, and without decentralization the network will be > > vulnerable to attack." > > > > Followed by a link to learn more, a download link and news. > > > > Is this sufficiently comprehensible to newbies? I guess so, but it > > doesn't really answer the question! > I think it's quite good actually! I think "Without anonymity there can > never be true freedom of speech") is a bit subjective though. > >>> Alternatives? Clearly anonymity is a direct consequence of the overriding > >>> goal of thwarting censorship. > >> Ala "The anonymity of Freenet makes true freedom of speech possible" > > > > Freenet is free software which lets you anonymously share files, browse and > > publish "freesites" (web sites accessible only through Freenet) and chat on > > forums, without fear of censorship. Freenet is decentralised to make it > > less vulnerable to attack. > > > > Or even: > > > > Freenet is free software which lets you anonymously share files, browse and > > publish "freesites" (web sites accessible only through Freenet) and chat on > > forums, without fear of censorship. Freenet is decentralised to make it > > less vulnerable to attack, and if used in "darknet" mode, where users only > > connect to their friends, is very difficult to detect. > > > > ??? > > Sounds better to me. Okay, I have pushed that one. One possible criticism is that it does not emphasise censorship resistance enough. The old version makes it very clear that our key goal is to resist censorship and everything else flows from that. 'Freenet is free software which lets you share files, browse and publish "freesites" (web sites accessible only through Freenet) and chat on forums, without fear of censorship. To prevent censorship, users are anonymous, and Freenet is decentralised. If used in "darknet" mode, where users only connect to their friends, it is very difficult to detect or block.' ??? > > >> Very annoying to be asked to install a second > >> browser. In this case, a third (using FF with IE as backup. And user > >> is > >> asked not to use IE). More FUD about history leaks. > > FUD stands for Fear, Uncertainty and Doubt. Unfortunately, the warnings > > about browser history stealing are factually true. Perhaps there is an > > argument for not naming such attacks if this intimidates people? Is the > > problem with IE important? There are possibilities for working around > > it, there has never been much enthusiasm for implementing them (even > > from ian who tends to be usability oriented). > Exactly. The user is fears the consequences of history leaks and is > uncertain what he ought to do, and thereby doubts his security and > privacy using Freenet. > >>> He knows what he needs to do - use a separate browser. Don't we make that > >>> clear? It may be annoying but it is clear, no? > >> It is indeed very clear, but as you say, also damn annoying. If > >> possible, I think we should avoid annoying the user. > > > > Well, any suggestions you may have... afaics the best option on windows is > > to run Chrome in incognito mode, and tell the wizard not to show the > > warning. But in that case we need to warn the user if they ever use another > > browser - and we can't tell the difference between Chrome in incognito mode > > and Chrome not in incognito mode, so I think we should display the warning > > anyway, we just need to rewrite it a bit for the case where we are using > > Chrome in incognito mode: > > > > "You must always use a browser with incognito mode for
Re: [freenet-dev] Update to the swedish translation
On Thursday 18 June 2009 16:10:56 Cooo . wrote: > Hi all. > > Here is an minor update to the swedish translation, please commit. > Applied to git rev 1ce0954, thanks. 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] Asynchronous image loading
On Thursday 18 June 2009 17:02:06 sashee wrote: > With async image loading,activelinks will be loaded too. > As for the 21 secs. It can be decreased, but only to sacrifice > something else. 21 sec means the client can skip a keepalive, and fail > after the second. Since it's localhost, it's unlikely to fail even 1, > so it can be reduced to 11 sec. If we send keepalives more frequently, > it will consume more resources for all tabs to send them, but it will > reduce further the time needed to detect tab closes. It is easily > configured with constants though. There is no callback on a page being closed? > > sashee > > On Thu, Jun 18, 2009 at 11:33 AM, xor wrote: > > On Wednesday 17 June 2009 16:36:26 sashee wrote: > >> Hello folks! > >> > >> Some days ago, I've talked with nextgens about toadlet > >> continuations(it's asynchronous request processing), and he had a > >> point that when the user opens a site with lots of images, then it > >> needs many connections open for a long time, and it spawns many > >> threads at serverside, which is resource demanding and some OSes don't > >> allow. The browser has a maximum connection limit to the site, but the > >> user can overwrite it. But at the default, firefox opens only 2-3 > >> connections to fetch the images, this way freenet don't start all the > >> fetching, just what is requested. So one problem is that if a user > >> alters the browser's config, then it will result many threads, if not, > >> then freenet can't download all the content simultanously. > >> I think with pushing, I'm working on, can be a solution for both > >> problems. When the page loads, freenet start fetching all the images, > >> and the browser gets the progress with 1 permanent connection. There > >> can be an image eg. "Image is loading...10%" and after some progress > >> change to 20% and so on, and when finishes downloading, it shows or > >> says eg. "Image finished loading, click to display". If it's done, we > >> don't need continuations anymore. Ofc it would need javascript to be > >> enabled. > >> > >> What you think? > > > > I filed a bug on that regarding activelinks, containing one possible way to > > solve it via javascript: > > > > https://bugs.freenetproject.org/view.php?id=3207 > > > > So when you implement it, please also do it for activelinks, as they are > > nice > > to have and could be re-enabled then. > > > > xor 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] need graphic design help
On Wednesday 17 June 2009 20:43:19 Caco Patane wrote: > > I think he means that users in "poor" areas usually run pirated versions > > of XP with the included IE6. Many of these installations won't have a > > functional Windows Update because of the "Genuine Advantage" stuff > > Microsoft pushes through it. Wich means that they won't get IE updates > > automatically, and probably won't/can't upgrade manually. > > That's it! But not only poor areas, only companies and laptop users > run genuine software. Brand computers (Dell, IBM, etc) are only > purchased by multinational corporations. I used an original copy of > windows for a work in a big corp, not even un goverment offices (kinda > fun). I think that the same scenarios goes for all latin america... > Venezuela, Bolivia and Cuba are in "delicate" positions regarding > freedom of speech. Chavez already closed a TV channel =D > > For the PNG thing, we can use the PNG with transparent background and > in the tag include: > > > > No new image is needed, those javascripts "fix" it. IMHO that is a good idea if it is not disruptive. Can you deal with it? 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] About the website
On Wednesday 17 June 2009 20:09:53 3BUIb3S50i 3BUIb3S50i wrote: > Can you make a link to another languages? (Like french wiki.) See > https://bugs.freenetproject.org/view.php?id=2915 If people are interested in translating the website we can serve different content for different languages. So far we have a partial german translation and one other which is *really* partial. Both are out of date. > > On Wed, Jun 17, 2009 at 1:57 PM, Matthew Toseland > wrote: > > > On Wednesday 17 June 2009 07:40:18 Arne Babenhauserheide wrote: > > > Am Mittwoch, 17. Juni 2009 05:26:25 schrieb Luke771: > > > > Browse and publish 'freesites' (Freenet-hosted websites) > > > > > > This one sounds very nice to me. It gets people into the freenet-speech > > and at > > > the same time tells them why we use it (what's the difference between a > > > freesite and a normal website). > > > > Currently it is: > > > > Freenet is free software which lets you anonymously share files, browse and > > publish "freesites" (web sites accessible only through Freenet) and chat on > > forums, without fear of censorship. Users are anonymous, and Freenet is > > entirely decentralised. Without anonymity there can never be true freedom of > > speech, and without decentralisation the network would be vulnerable to > > attack. 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] The new blue gradient website background
On Wednesday 17 June 2009 02:06:06 Daniel Cheng wrote: > Just a quick notes: > > Blue Gradient background won't work, because: > > -- BLUE have low contrast with the black text I disagree. It's easy to read for me. > -- our rabbit logo is blue, even lower contrast I think it's enough. > -- the website ian suggested ( getfirefox/ jquery) > and other well-design webpage does NOT > use gradient as _text_ background AT ALL.. > ___ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090618/5ab3a969/attachment.pgp>
[freenet-dev] Asynchronous image loading
On Wednesday 17 June 2009 16:36:26 sashee wrote: > Hello folks! > > Some days ago, I've talked with nextgens about toadlet > continuations(it's asynchronous request processing), and he had a > point that when the user opens a site with lots of images, then it > needs many connections open for a long time, and it spawns many > threads at serverside, which is resource demanding and some OSes don't > allow. The browser has a maximum connection limit to the site, but the > user can overwrite it. But at the default, firefox opens only 2-3 > connections to fetch the images, this way freenet don't start all the > fetching, just what is requested. So one problem is that if a user > alters the browser's config, then it will result many threads, if not, > then freenet can't download all the content simultanously. > I think with pushing, I'm working on, can be a solution for both > problems. When the page loads, freenet start fetching all the images, > and the browser gets the progress with 1 permanent connection. There > can be an image eg. "Image is loading...10%" and after some progress > change to 20% and so on, and when finishes downloading, it shows or > says eg. "Image finished loading, click to display". If it's done, we > don't need continuations anymore. Ofc it would need javascript to be > enabled. > > What you think? I filed a bug on that regarding activelinks, containing one possible way to solve it via javascript: https://bugs.freenetproject.org/view.php?id=3207 So when you implement it, please also do it for activelinks, as they are nice to have and could be re-enabled then. xor -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090618/d9c47ebc/attachment.pgp>
[freenet-dev] Update to the swedish translation
ockan
UserAlertManager.clickForMore=Klicka p? en upplysning f?r att f? mer
information eller f?r att ta bort den.
Node.opennetEnabledLong=Aktivera os?kert l?ge (ocks? k?nt som opennet)?
Om detta ?r aktiverat kommer din nod att automatiskt utbyta nodreferenser
med fr?mlingar (till skillnad mot tillf?rlitliga V?nner). Detta betyder
att din nod ?r l?ttare att attackera och att den inte ?r lika privat
l?ngre. Om du k?nner tillr?ckligt med personer som k?r Freenet s? b?r du
enbart k?ra med V?nner och d?rmed st?nga av denna option.
Node.outBWLimitLong=Maximal uppladdningshastighet (bytes per sekund),
noden ska n?stan aldrig ?verskrida detta v?rde.
Node.outBWLimit=Maximal uppladdningshastighet (bytes per sekund)
Node.inBWLimitLong=Maximal nedladdningshastighet (bytes per sekund),
noden ska n?stan aldrig ?verskrida detta v?rde, -1 = 4 * inst?lld
uppladdningshastighet.
Node.storeBloomFilterSize=Storlek p? Bloom filter (totalt) i bytes
SecurityLevelsToadlet.fullTitle=S?kerhetsniv?er f?r ${name}
BookmarkManager.defaultBookmarks=Standard bokm?rken
UpdatedVersionAvailableUserAlert.shortReadyNotArmed=Noden har laddat ner
en ny version av Freenet men beh?ver din till?telse f?r att installera
den.
UpdatedVersionAvailableUserAlert.shortArmed=Din nod laddar ner en version
av Freenet och kommer att starta om n?r det ?r klart.
OpennetConnectionsToadlet.fullTitle=${counts} Fr?mlingar (Icke
tillf?rlitliga noder) anslutna till ${name}
OpennetConnectionsToadlet.peersListTitle=Fr?mlingar (Automatiskt anslutna
fr?mlingar tillagda av noden)
WelcomeToadlet.searchFreenet=S?k!
WelcomeToadlet.searchBoxLabel=S?k i Freenet (kan ta l?ng tid)
WelcomeToadlet.searchPluginNotLoaded=S?k pluginen ?r inte startad!
WelcomeToadlet.requestCount=F?rfr?gningar: ${total}
BookmarkEditorToadlet.invalidNameTitle=Ogiltigt namn
BookmarkEditorToadlet.addDefaultBookmarks=?terst?ll standardbokm?rkena
ClockProblemDetectedUserAlert.text=Freenet har uppt?ckt att din dators
klocka (tid och datum) inte g?r r?tt. Noden kommer inte fungera korrekt
innan du har ?tg?rdat detta och startat om noden.
End
--
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com
-- next part --
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090618/2570860e/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: freenet.l10n.se.override.properties
Type: application/octet-stream
Size: 7132 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090618/2570860e/attachment.obj>
Re: [freenet-dev] Asynchronous image loading
With async image loading,activelinks will be loaded too. As for the 21 secs. It can be decreased, but only to sacrifice something else. 21 sec means the client can skip a keepalive, and fail after the second. Since it's localhost, it's unlikely to fail even 1, so it can be reduced to 11 sec. If we send keepalives more frequently, it will consume more resources for all tabs to send them, but it will reduce further the time needed to detect tab closes. It is easily configured with constants though. sashee On Thu, Jun 18, 2009 at 11:33 AM, xor wrote: > On Wednesday 17 June 2009 16:36:26 sashee wrote: >> Hello folks! >> >> Some days ago, I've talked with nextgens about toadlet >> continuations(it's asynchronous request processing), and he had a >> point that when the user opens a site with lots of images, then it >> needs many connections open for a long time, and it spawns many >> threads at serverside, which is resource demanding and some OSes don't >> allow. The browser has a maximum connection limit to the site, but the >> user can overwrite it. But at the default, firefox opens only 2-3 >> connections to fetch the images, this way freenet don't start all the >> fetching, just what is requested. So one problem is that if a user >> alters the browser's config, then it will result many threads, if not, >> then freenet can't download all the content simultanously. >> I think with pushing, I'm working on, can be a solution for both >> problems. When the page loads, freenet start fetching all the images, >> and the browser gets the progress with 1 permanent connection. There >> can be an image eg. "Image is loading...10%" and after some progress >> change to 20% and so on, and when finishes downloading, it shows or >> says eg. "Image finished loading, click to display". If it's done, we >> don't need continuations anymore. Ofc it would need javascript to be >> enabled. >> >> What you think? > > I filed a bug on that regarding activelinks, containing one possible way to > solve it via javascript: > > https://bugs.freenetproject.org/view.php?id=3207 > > So when you implement it, please also do it for activelinks, as they are nice > to have and could be re-enabled then. > > xor > > ___ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Update to the swedish translation
Hi all.
Here is an minor update to the swedish translation, please commit.
ConnectivityToadlet.title=Internetanslutningar för ${nodeName}
SSL.enable=Aktivera SSL support?
SSL.enableLong=Aktivera SSL support?
QueueToadlet.downloadFilesInstructions=Du kan klistra in en lista med
Freenetnycklar att ladda ner i boxen nedanför (en per linje)
QueueToadlet.insertFileResetForm=Återställ formulär
QueueToadlet.titleUploads=Uppladdningar för ${nodeName}
QueueToadlet.downloadFiles=Massnedladdningar
QueueToadlet.totalQueuedUploads=Totalt köade uppladdningar: ${size}
QueueToadlet.uploadSucceeded=Filen ${filename} (size ${size}) har laddats
upp. ${link}Klicka här${/link} för att öppna filen.
QueueToadlet.awaitingCompression=Väntar
QueueToadlet.totalQueuedDownloads=Totalt köade nedladdningar: ${size}
QueueToadlet.titleDownloads=Nedladdningar för ${nodeName}
QueueToadlet.insertFileBrowseButton=Bläddra filer
SecurityLevels.friendsThr eatLevelShort=Skydd mot att Vänner attackerar
din anonymitet
SecurityLevels.userAlertFriendsThreatLevel=Skydd mot att Vänner
attackerar din anonymitet: ${level}
SecurityLevels.physicalThreatLevelShort=Skydd ifall din dator
omhändertages eller blir stulen
SecurityLevels.userAlertPhysicalThreatLevel=Skydd ifall din dator
omhändertages eller blir stulen: ${level}
SecurityLevels.userAlertExtro=Dessa inställningar kan ändras
${link}här${/link}.
SecurityLevels.networkThreatLevelShort=Skydd mot att en främling
attackerar dig över Internet
SecurityLevels.userAlertNetworkThreatLevel=Skydd mot att en främling
attackerar dig över Internet: ${level}
SecurityLevels.physicalThreatLevel.choice.NORMAL=Jag är bekymrad.
SecurityLevels.physicalThreatLevel.choice.LOW=Jag är inte bekymrad.
SecurityLevels.networkThreatLevel.choice.LOW=Jag bryr mig inte om
övervakning utan vill ha maximal prestanda.
ConfigToadlet.needRestartTitle=Noden behöver startas om
ConfigToadlet.title=Nodinställningar
ConfigToadlet.needRestartShort=Vissa ändringar kräver en omstart för att
fungera, vänligen starta om noden.
ConfigToadlet.fullTitle=Nodinställningar för ${name}
ConfigToadlet.needRestart=Vissa inställningar kräver att noden startas
om.
ConfigToadlet.node.updater=Automatisk uppdatering
IPDetectorPluginManager.noConnectivity=Din internetanslutning verkar inte
stödja UPD.Om inte detta är en felbedömmning så är det inte troligt att
du kan använda Freenet.
IPDetectorPluginManager.seriousConnectionProblems=Allvarliga problem att
ansluta:
FProxyToadlet.uploadsTitle=Uppladdningar
FProxyToadlet.categoryTitleFriends=Anslut till dina vänner för att
förbättra Freenet's prestanda och säkerhet
FProxyToadlet.downloadsTitle=Nedladdningar
FProxyToadlet.categoryConfig=Konfiguration
FProxyToadlet.addFriend=Anslut till en vän som använder Freenet för att
förbättra din säkerhet
FProxyToadlet.downloads=Filer som laddas ner från Freenet
FProxyToadlet.insertFreesite=Ladda upp en websida anonymt till Freenet
FProxyToadlet.seclevelsTitle=Säkerhetsnivåer
FProxyToadlet.categoryFriends=Vänner
FProxyToadlet.insertFreesiteTitle=Ladda upp en Freesite
FProxyToadlet.categoryQueue=Fildelning
FProxyToadlet.categoryTitleBrowsing=Surfa på Freenet
FProxyToadlet.categoryTitleQueue=Upp och nedladdningar
FProxyToadlet.categoryBrowsing=Surfning
FProxyToadlet.openAsThawIndex=${link}Klicka här${/link} för att öppna
filen med thaw index browser (Läs varningen ovan!).
FProxyToadlet.uploads=Filer som laddas upp till Freenet
FProxyToadlet.addFriendTitle=Lägg till en vän
FProxyToadlet.categoryTitleConfig=Konfigurera Freenet
PluginManager.deleteFailedPluginButton=Starta inte vid nästa Freenet
uppstart
DarknetConnectionsToadlet.darknetFnpPort=Darknet FNP: ${port}/UDP
(Används för att ansluta till tillförlitliga noder d.v.s. Vänner;
Vidarebefodra denna port om det är möjligt)
DarknetConnectionsToadlet.opennetFnpPort=Opennet FNP: ${port}/UDP
(Används för att ansluta till icke tillförlitliga noder d.v.s.
Främlingar; vidarebefodra denna port om det är möjligt)
DarknetConnectionsToadlet.peerAdditionCode.OK=Tillagd
DarknetConnectionsToadlet.peerAdditionCode.INTERNAL_ERROR=Internt fel
DarknetConnectionsToadlet.peerAdditionCode.ALREADY_IN_REFERENCE=Referensen
finns redan
DarknetConnectionsToadlet.peerAdditionCode.TRY_TO_ADD_SELF=Du försökte
att lägga till dig själv
PproxyToadlet.unloadPurge=Radera pluginen från cachen
TranslationToadlet.title=Översättning
FirstTimeWizardToadlet.currentPrefix=Nuvarande storlek:
FirstTimeWizardToadlet.autodetectedSuggestedLimit=Rekommenderad:
FirstTimeWizardToadlet.bandwidthLimitLong=Välj den typ av
internetanlutning och hastighet (nedladdning/uppladdning) du har från
listan nedanför.
FirstTimeWizardToadlet.autoUpdateAutodeploy=Håll Freenet uppdaterat
automatiskt.
FirstTimeWizardToadlet.currentSpeed=Nuvarande gräns:
FirstTimeWizardToadlet.chooseNodeName=Du måste ange ett namn på din nod!
FetchException.shortError.21=För stor
SimpleToadletServer.enableActivelinks=Aktivera activelinks?
PeerManagerUserAlert.clockProblemTitle=Problem med klockan
UserAlertMa
Re: [freenet-dev] The new blue gradient website background
On Wednesday 17 June 2009 02:06:06 Daniel Cheng wrote: > Just a quick notes: > > Blue Gradient background won't work, because: > > -- BLUE have low contrast with the black text I disagree. It's easy to read for me. > -- our rabbit logo is blue, even lower contrast I think it's enough. > -- the website ian suggested ( getfirefox/ jquery) > and other well-design webpage does NOT > use gradient as _text_ background AT ALL.. > ___ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl 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] Asynchronous image loading
On Wednesday 17 June 2009 16:36:26 sashee wrote: > Hello folks! > > Some days ago, I've talked with nextgens about toadlet > continuations(it's asynchronous request processing), and he had a > point that when the user opens a site with lots of images, then it > needs many connections open for a long time, and it spawns many > threads at serverside, which is resource demanding and some OSes don't > allow. The browser has a maximum connection limit to the site, but the > user can overwrite it. But at the default, firefox opens only 2-3 > connections to fetch the images, this way freenet don't start all the > fetching, just what is requested. So one problem is that if a user > alters the browser's config, then it will result many threads, if not, > then freenet can't download all the content simultanously. > I think with pushing, I'm working on, can be a solution for both > problems. When the page loads, freenet start fetching all the images, > and the browser gets the progress with 1 permanent connection. There > can be an image eg. "Image is loading...10%" and after some progress > change to 20% and so on, and when finishes downloading, it shows or > says eg. "Image finished loading, click to display". If it's done, we > don't need continuations anymore. Ofc it would need javascript to be > enabled. > > What you think? I filed a bug on that regarding activelinks, containing one possible way to solve it via javascript: https://bugs.freenetproject.org/view.php?id=3207 So when you implement it, please also do it for activelinks, as they are nice to have and could be re-enabled then. xor 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] Asynchronous image loading
On Wednesday 17 June 2009 20:19:25 sashee wrote: > Ok, I'll schedule that then. > > One thing that *is* critical is that we stop loading the images if the user > > closes the page, but afaics the existing infrastructure will do that. > > I really dont think that anything gets notified when the user closes > the tab. So I dont think fetching is stopped then. > > As I see the prefetching has a 1 minute timeout, so it isn't really > solving things. Inline prefetch fetches stuff, but only those, that > are fast, and kills the others. And the browser's request fetches the > other(almost all) images, 2(3) at a time. Asyncronous fetching would > solve that problem, because it can notify(and cancel) the fetches when > the user actually closes the tab. Or at least within 21 seconds of closing the tab. :) Can you improve on that? > > sashee > > On Wed, Jun 17, 2009 at 8:28 PM, Matthew > Toseland wrote: > > On Wednesday 17 June 2009 19:23:22 sashee wrote: > >> So my question is: Is it needed? If it helps, I'll do it before the > >> midterm evals, but if it doesnt improve anything, then no need to > >> program it. > > > > Yes. IMHO it is important. Prefetching has never worked well on new nodes, > > and doesn't solve the connection limit problem anyway. Also the > > infrastructure will be interesting as later on we may want notifications on > > loaded pages (e.g. "there is a more recent version of this page available", > > but maybe also critical node events). > > > > Feel free to make a very basic implementation where you either have the > > loaded image or you have a loading graphic with no indication of how far it > > has got. *Ideally* we'd have the loading images be dependant on how far the > > request has got, but this isn't essential, certainly not for a first > > approximation ... another interesting option would be to show a progress > > bar showing the overall progress, ETA, etc. One thing that *is* critical is > > that we stop loading the images if the user closes the page, but afaics the > > existing infrastructure will do that. > >> > >> On Wed, Jun 17, 2009 at 5:44 PM, sashee wrote: > >> > Ok, thats true. But the browser won't show an image till all the image > >> > above are shown, because it uses 2-3 connections to fetch the images > >> > sequentially. It may happen that a few image that fetches very slowly > >> > will hang all the others, even if they are completely present. > >> > > >> > sashee > >> > > >> > On Wed, Jun 17, 2009 at 4:46 PM, Daniel Cheng >> > gmail.com> wrote: > >> >> On 17/6/2009 22:36, sashee wrote: > >> >>> this way freenet don't start all the > >> >>> fetching, just what is requested... When the page loads, freenet > >> >> ?> start fetching all the images, > >> >> > >> >> Did you look at your /config/fproxy page ? > >> >> There is an option called "Enable prefetching of inline images" .. > >> >> > >> >>> What you think? > >> >> > >> >> :) > > > > ___ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > ___ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -- 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/20090618/a705fbe3/attachment.pgp>
