Re: [freenet-dev] Usability test results
On Friday 15 May 2009 17:05:09 Robert Hailey wrote: On May 14, 2009, at 5:06 PM, Matthew Toseland wrote: On Thursday 14 May 2009 20:36:31 Robert Hailey wrote: On May 14, 2009, at 12:17 PM, Matthew Toseland wrote: Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) I think that it should be possible to automatically detect this. Specifically, if we detect that our peer has the same external address as us, try and connect locally. Is that a reliable indicator? Not very (what if it changes?) ... we don't want darknet peers to cause us to connect to addresses on our LAN ... otherwise the solution is simply to try the local addresses included ... I agree that we don't want to try the local addresses of ~all~ our peers; local connections are in principal an exception and not cause enough to be sending so much local garbage handshaking traffic (that could give away a freenet node). But I think this is the right way to go... If it is not defined for a given peer (allow/disallow local connections), then we could just calculate the default boolean as his.extAddresses.containsAny(my.extAddresses) if it matches, then there is an excellent chance of it being a local connection (99%). If it changes, that's great! The decision to try local connections would change too! As it's probably a laptop that has floated out of the LAN (and we would want to stop sending handshakes to the local address anyway). At worst we might send a few garbage handshakes to local non- freenet machine until we connect to the node find it's new external address. The reason I think this would solve the problem because (I think) the principal reason that the nodes could not communicate is because the gateway would have to send a packet to itself (many inexpensive or firewalled ones will not). e.g. internal - firewall - external (generally works w/ current countermeasures) internal -- firewall internal -- Does not work (at least for me). So what I propose is really an extension of detecting the problem (the gateway which has the same external ip). Don't know about multihoming, but I presume that this is works in the common case. Nonetheless it is highly unreliable as a way to detect it with dynamic external IP address, especially given that the two nodes are unable to communicate by any other means. 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] Usability test results
On Friday 15 May 2009 17:05:09 Robert Hailey wrote: On May 14, 2009, at 5:06 PM, Matthew Toseland wrote: On Thursday 14 May 2009 20:36:31 Robert Hailey wrote: On May 14, 2009, at 12:17 PM, Matthew Toseland wrote: Once connected to my node, it repeatedly RNFed on the top block of TUFI. Performance with one peer is expected to be poor, but it is worse than IMHO it could be. Some sort of fair sharing scheme ought to allow a darknet peer that isn't doing much to have a few requests accepted while we are rejecting tons of requests from other darknet peers and opennet peers. (#3101) I second that, but I'm not sure as to the best implementation. On the surface this appears to be the same issue as balancing local/ remote requests. i.e. if your node is busy doing everyone else's work, your requests should take clear advantage when you finally get around to clicking a link. Possibly. It is indeed a load balancing problem. Queueing will help, or maybe simulated queueing. I think this conflicts with the current throttling mechanism; piling on requests till one or both nodes say 'enough', Is this how it works now? Yep. To the best of my understanding... Q: How do we determine if we are going to take a remote request? A: If there is room to incur it's expected bandwidth. Premise-1: all chks transfer at an equal rate Result-1: new transfers squeeze bandwidth from other transfers. Result-2: a node will accept any number of transfers until such a point that all of them would go over the maximum allowed transfer time. Effectively making every transfer to the slowest-allowed transfer (not counting local traffic or non-busy nodes). This is why I advocated lowering the slowest transfer time as a general speedup. Which we tried, and it caused a massive slowDOWN. Mostly because most requests do not result in a transfer, so we need a substantial number of requests to compensate for that. The real solution is a bulk flag, but we cannot implement that until 0.7.5 has shipped. and if we reserve some space we will not hit our bandwidth goal. Or that requests are actually competing like collisions on a busy ethernet channel rather than having an order. Yes, it is very much like that. Does that mean that the logical alternative is token passing? In fact... guarantee-able request acceptance (token passing), might actually be a logical prerequisite for a fair-queueing system. Interestingly any node can measure how many requests it can accept right now (for bandwidth), but only can guess as to it's peers (by backoff); so then, we may well accept requests which we cannot make good on, because our peers cannot accept them (ethernet collision logic at every hop). Yes. On 0.5 we tried to estimate the rate at which we could accept requests and publish this, but we could never take our peers' inter-request times into account when calculating our own without getting network collapse. Some system involving queueing is likely the best we can achieve. Token passing (advertising to several nodes when we have an available slot) is really just an essential optimisation for queueing. But by definition queueing results in all requests spending longer on a hop, and some requests spending much longer (and perhaps timing out). Simulated queueing (randomly dropping requests to maintain queue lengths, but routing immediately those we accept) might be an alternative for lower latency at the cost of lower accuracy. Maximum queue times could be radically different for requests with and without the bulk flag. One thing that I was playing around with earlier was re-factoring PacketThrottle to be viewed from the queue-side. Rather than sendThrottledPacket blocking till a good time to enqueue a message based on the throttle, that all the packets would be serially available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns the next 'n' packets). Good idea... I thought it was somewhat like that already? It is important in some cases for it to block... Only in that they feed an outbound message queue rather than actually sending a packet. But it looks to me like a bit of cruft from a previous design. In any case, you have a design note in the comments of PacketThrottle that it would be better to have a sorted list or red/black tree rather than a ticket system (where all threads wakeup); maybe a new class needs to be written (BulkQueue) that *only* interleaves waiters (round robin?) and the packet throttle then used only for actually sending packets. Yeah... 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] Usability test results
On Monday 18 May 2009 14:50:30 Thomas Sachau wrote: Arne Babenhauserheide schrieb: On Saturday, 16. May 2009 16:02:19 Thomas Sachau wrote: Additionally, Gentoo is about choice, if there is a warning, the user can choose, with a forcing script, there is no choice, which is a bad idea for this philosophy, therefor i vote against such a script for linux. But in Gentoo it would also be possible to add a use flag to select the browser, which just tells freenet which browser to use. Do you know the numbers of possible browsers? You dont want to add a useflag for each of them and additionally this would force the user to use exactly the one browser selected by useflag. Additionally, what happens, when the selected browser has no privacy mode enabled, while another has it? This was and still is no real option. Simple and easy is only the warning page, everyone sees it, everyone can act as written there. All choices still open and if anyone chooses to act like an idiot, it is his own problem. It is not simple and easy, because the user sees the warning page, and has to act on it. We should call a secure browser in the first place, and in particular, the Browse Freenet link, which everyone who can't memorise http://127.0.0.1:/ will use, should start either a browser in incognito mode or a browser chosen by the user for browsing Freenet. 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] Usability test results
On Monday 18 May 2009 18:03:50 Clément wrote: Le samedi 16 mai 2009 20:10:00, Matthew Toseland a écrit : On Saturday 16 May 2009 15:02:19 Thomas Sachau wrote: Matthew Toseland schrieb: On Friday 15 May 2009 16:35:40 Thomas Sachau wrote: Matthew Toseland schrieb: On Thursday 14 May 2009 18:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Why would that be bad? What if i dont want to do use the Wizard? Also, if i removed the wizard done line (intentinally or by mistake), a new run would remove my custom settings. With the option, i can just stop the wizard and no harm done. If you know enough to skip the wizard you should shutdown the node, edit the config file and tell the node you have done the wizard! Is there a need for editing the config file? You can set everything with the config section too, but without the i want to do it myself, you cant disable the wizard from the GUI. Related idea: We should maybe tell the user in the installer that they should use a separate browser for Freenet, rather than in the wizard? And then let them choose one, and then use it when they click on the icon to browse Freenet? (#3104) This would produce additional work for people packaging freenet, since they would have to warn the user themselves, while users tend to ignore the output of the package manager. So this would lower the chance of people noticing the request for a different freenet browser/profile and therefor i am against it. I suggest the current way: Warning during first call of the webinterface like it is currently done. Well, maybe on linux, with the packages that we don't have yet... Did you miss the Gentoo ebuilds? Isnt it a goal to get other distros to package it too? Just because it did not happen until now, doesnt mean it wont happen some time in the future. May just need more time since Gentoo as source based distro may be a bit better for packages than binary distros. No, it is a goal to package it with private repositories. Having a debian package that is frozen for 3 years is not useful at the present time. And if we have it for linux, why would you like to add additional code for windows (both in the installer and in freenet, which would have to detect the OS and then decide to show the warning or not)? Well, we could do something similar for *nix, no? Launch a suitable privacy enabled browser when the user runs the browse-freenet script? You dont know the user system. While windows user systems may be similar to each others, this is not true for linux. Where would you place that script? How would you check which browser the user wants to use? This idea looks more like the way user handling is done on windows or ubuntu: Expect him to know nothing and try to do everything for him. Might be nice for beginners and if it works, but makes things worse for experienced users, who want to do it different and also makes it harder, if there are problems. Imho you cant beat stupidity. Either users read a message and act the right way or they dont. You cannot prevent them from doing bad things. Additionally, Gentoo is about choice, if there is a warning, the user can choose, with a forcing script, there is no choice, which is a bad idea for this philosophy, therefor i vote against such a script for linux. Well, we already have a Browse Freenet script on all three platforms. Currently it detects browsers that we know about. You don't have to use it if you don't want to. But we should extend it to use incognito mode if possible, and to favour browsers with such support. I dunno how we can determine whether such a mode works with the particular installed version though... I don't see the point forcing the user to choose. I don't see the point displaying a warning neither btw : should we detect all the potentials security threats (or unused benefits) on the user's system ? Things like that are just waste of time. What would be good instead is a documentation about how to have a secure environment in which you can run freenet, and display a link to it during the wizard (or display the howto directly). Additional code to detect if the user use freenet in a secure environment is just a waste of time. Good documentation isn't. Freenet should, like all security software, be secure by default. When it cannot be secure it should TELL THE USER. We are
Re: [freenet-dev] Usability test results
On Monday, 18. May 2009 15:50:30 Thomas Sachau wrote: Do you know the numbers of possible browsers? You dont want to add a useflag for each of them and additionally this would force the user to use exactly the one browser selected by useflag. Additionally, what happens, when the selected browser has no privacy mode enabled, while another has it? This was and still is no real option. Simple and easy is only the warning page, everyone sees it, everyone can act as written there. All choices still open and if anyone chooses to act like an idiot, it is his own problem. I agree, it sounds most reasonable, and it worked for me. Maybe it could be possible to reorder the list of freenet in the wizard / on the warning. 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] Usability test results
On Saturday, 16. May 2009 16:02:19 Thomas Sachau wrote: Additionally, Gentoo is about choice, if there is a warning, the user can choose, with a forcing script, there is no choice, which is a bad idea for this philosophy, therefor i vote against such a script for linux. But in Gentoo it would also be possible to add a use flag to select the browser, which just tells freenet which browser to use. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - 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] Usability test results
On Sunday, 17. May 2009 00:59:13 Matthew Toseland wrote: Not much point hiding it if you're broadcasting the existence of nodes via MDNSDiscovery! ...you're right for OpenNet... should have seen that before. I assume only a full steganographic announcement framework could help there (have specific ways to hide a freenet announcement in innocent announcements). 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] Usability test results
Arne Babenhauserheide schrieb: On Saturday, 16. May 2009 16:02:19 Thomas Sachau wrote: Additionally, Gentoo is about choice, if there is a warning, the user can choose, with a forcing script, there is no choice, which is a bad idea for this philosophy, therefor i vote against such a script for linux. But in Gentoo it would also be possible to add a use flag to select the browser, which just tells freenet which browser to use. Do you know the numbers of possible browsers? You dont want to add a useflag for each of them and additionally this would force the user to use exactly the one browser selected by useflag. Additionally, what happens, when the selected browser has no privacy mode enabled, while another has it? This was and still is no real option. Simple and easy is only the warning page, everyone sees it, everyone can act as written there. All choices still open and if anyone chooses to act like an idiot, it is his own problem. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
Le samedi 16 mai 2009 20:10:00, Matthew Toseland a écrit : On Saturday 16 May 2009 15:02:19 Thomas Sachau wrote: Matthew Toseland schrieb: On Friday 15 May 2009 16:35:40 Thomas Sachau wrote: Matthew Toseland schrieb: On Thursday 14 May 2009 18:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Why would that be bad? What if i dont want to do use the Wizard? Also, if i removed the wizard done line (intentinally or by mistake), a new run would remove my custom settings. With the option, i can just stop the wizard and no harm done. If you know enough to skip the wizard you should shutdown the node, edit the config file and tell the node you have done the wizard! Is there a need for editing the config file? You can set everything with the config section too, but without the i want to do it myself, you cant disable the wizard from the GUI. Related idea: We should maybe tell the user in the installer that they should use a separate browser for Freenet, rather than in the wizard? And then let them choose one, and then use it when they click on the icon to browse Freenet? (#3104) This would produce additional work for people packaging freenet, since they would have to warn the user themselves, while users tend to ignore the output of the package manager. So this would lower the chance of people noticing the request for a different freenet browser/profile and therefor i am against it. I suggest the current way: Warning during first call of the webinterface like it is currently done. Well, maybe on linux, with the packages that we don't have yet... Did you miss the Gentoo ebuilds? Isnt it a goal to get other distros to package it too? Just because it did not happen until now, doesnt mean it wont happen some time in the future. May just need more time since Gentoo as source based distro may be a bit better for packages than binary distros. No, it is a goal to package it with private repositories. Having a debian package that is frozen for 3 years is not useful at the present time. And if we have it for linux, why would you like to add additional code for windows (both in the installer and in freenet, which would have to detect the OS and then decide to show the warning or not)? Well, we could do something similar for *nix, no? Launch a suitable privacy enabled browser when the user runs the browse-freenet script? You dont know the user system. While windows user systems may be similar to each others, this is not true for linux. Where would you place that script? How would you check which browser the user wants to use? This idea looks more like the way user handling is done on windows or ubuntu: Expect him to know nothing and try to do everything for him. Might be nice for beginners and if it works, but makes things worse for experienced users, who want to do it different and also makes it harder, if there are problems. Imho you cant beat stupidity. Either users read a message and act the right way or they dont. You cannot prevent them from doing bad things. Additionally, Gentoo is about choice, if there is a warning, the user can choose, with a forcing script, there is no choice, which is a bad idea for this philosophy, therefor i vote against such a script for linux. Well, we already have a Browse Freenet script on all three platforms. Currently it detects browsers that we know about. You don't have to use it if you don't want to. But we should extend it to use incognito mode if possible, and to favour browsers with such support. I dunno how we can determine whether such a mode works with the particular installed version though... I don't see the point forcing the user to choose. I don't see the point displaying a warning neither btw : should we detect all the potentials security threats (or unused benefits) on the user's system ? Things like that are just waste of time. What would be good instead is a documentation about how to have a secure environment in which you can run freenet, and display a link to it during the wizard (or display the howto directly). Additional code to detect if the user use freenet in a secure environment is just a waste of time. Good documentation isn't. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
Matthew Toseland skrev: Well, we already have a Browse Freenet script on all three platforms. Currently it detects browsers that we know about. You don't have to use it if you don't want to. But we should extend it to use incognito mode if possible, and to favour browsers with such support. I dunno how we can determine whether such a mode works with the particular installed version though... Best clue is to check the versions of the found browsers - or simply assume that the user has fairly up-to-date software and pass the switch anyway. Old browsers will probably just ignore the command line switch if they don't know about it. - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On Friday 15 May 2009 16:35:40 Thomas Sachau wrote: Matthew Toseland schrieb: On Thursday 14 May 2009 18:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Why would that be bad? What if i dont want to do use the Wizard? Also, if i removed the wizard done line (intentinally or by mistake), a new run would remove my custom settings. With the option, i can just stop the wizard and no harm done. If you know enough to skip the wizard you should shutdown the node, edit the config file and tell the node you have done the wizard! Related idea: We should maybe tell the user in the installer that they should use a separate browser for Freenet, rather than in the wizard? And then let them choose one, and then use it when they click on the icon to browse Freenet? (#3104) This would produce additional work for people packaging freenet, since they would have to warn the user themselves, while users tend to ignore the output of the package manager. So this would lower the chance of people noticing the request for a different freenet browser/profile and therefor i am against it. I suggest the current way: Warning during first call of the webinterface like it is currently done. Well, maybe on linux, with the packages that we don't have yet... Did you miss the Gentoo ebuilds? Isnt it a goal to get other distros to package it too? Just because it did not happen until now, doesnt mean it wont happen some time in the future. May just need more time since Gentoo as source based distro may be a bit better for packages than binary distros. No, it is a goal to package it with private repositories. Having a debian package that is frozen for 3 years is not useful at the present time. And if we have it for linux, why would you like to add additional code for windows (both in the installer and in freenet, which would have to detect the OS and then decide to show the warning or not)? Well, we could do something similar for *nix, no? Launch a suitable privacy enabled browser when the user runs the browse-freenet script? 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] Usability test results
* xor x...@gmx.li [2009-05-15 18:24:53]: On Thursday 14 May 2009 19:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. IMHO the current behavior is a bug though: We have the MDNS plugin, which is installed by default and should automatically (opennet-) connect nodes on a LAN. Did you even read the code? It was never intended to do that and doesn't. However it does not work because LAN connections are disallowed by default. IT WASN'T IMPLEMENTED AT ALL. signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
* Robert Hailey rob...@freenetproject.org [2009-05-15 13:04:58]: On May 15, 2009, at 11:57 AM, xor wrote: On Friday 15 May 2009 18:37:12 Thomas Sachau wrote: xor schrieb: On Thursday 14 May 2009 19:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. IMHO the current behavior is a bug though: We have the MDNS plugin, which is installed by default and should automatically (opennet-) connect nodes on a LAN. However it does not work because LAN connections are disallowed by default. Afaik that plugin is no longer installed by default. Why not? I like the idea of self-organizing Freenet on LANs very much :) Especially if you consider large public or private LANs where two people running Freenet might not even know each others, so they couldn't get manually connected. Hmmm... but does a node want to advertise that we are running freenet? Maybe dependent on the security level setting. In either case, a small network would have major issues if it was not also connected to the large network, Ever heard of darknet? and so I think still that automatically detecting locality based on external ip address would help (e.g. a node could preferentially keep any opennet peers that it finds as being local). That's what darknet connections are about. Opennet nodes connecting to the same darknet nodes is a BUG which has already been reported and has a ticket on mantis. signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
* xor x...@gmx.li [2009-05-15 22:07:34]: On Friday 15 May 2009 20:04:58 Robert Hailey wrote: On May 15, 2009, at 11:57 AM, xor wrote: On Friday 15 May 2009 18:37:12 Thomas Sachau wrote: xor schrieb: On Thursday 14 May 2009 19:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. IMHO the current behavior is a bug though: We have the MDNS plugin, which is installed by default and should automatically (opennet-) connect nodes on a LAN. However it does not work because LAN connections are disallowed by default. Afaik that plugin is no longer installed by default. Why not? I like the idea of self-organizing Freenet on LANs very much :) Especially if you consider large public or private LANs where two people running Freenet might not even know each others, so they couldn't get manually connected. Hmmm... but does a node want to advertise that we are running freenet? Maybe dependent on the security level setting. The more people confess that they are running Freenet, the more difficult it becomes to blame an individual as guilty for running it. Further, if you run opennet, you are screwed anyway, and MDNS is mostly useful for Opennet. In either case, a small network would have major issues if it was not also connected to the large network, and so I think still that automatically detecting locality based on external ip address would help (e.g. a node could preferentially keep any opennet peers that it finds as being local). Wouldn't it take much load off the internet, i.e. small bandwidth connections, if any nodes which are connected via LAN used the LAN for routing requests if possible? I think the LAN could behave like a single large node, i.e. requests for data which is stored within the LAN would be answered very fast, and much data could be stored if there are many nodes on a LAN. The idea is not new, at the beginning bloom-filter sharing was supposed to be for darknet nodes or local nodes. There is also a ticket on mantis describing that signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
Matthew Toseland schrieb: On Friday 15 May 2009 16:35:40 Thomas Sachau wrote: Matthew Toseland schrieb: On Thursday 14 May 2009 18:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Why would that be bad? What if i dont want to do use the Wizard? Also, if i removed the wizard done line (intentinally or by mistake), a new run would remove my custom settings. With the option, i can just stop the wizard and no harm done. If you know enough to skip the wizard you should shutdown the node, edit the config file and tell the node you have done the wizard! Is there a need for editing the config file? You can set everything with the config section too, but without the i want to do it myself, you cant disable the wizard from the GUI. Related idea: We should maybe tell the user in the installer that they should use a separate browser for Freenet, rather than in the wizard? And then let them choose one, and then use it when they click on the icon to browse Freenet? (#3104) This would produce additional work for people packaging freenet, since they would have to warn the user themselves, while users tend to ignore the output of the package manager. So this would lower the chance of people noticing the request for a different freenet browser/profile and therefor i am against it. I suggest the current way: Warning during first call of the webinterface like it is currently done. Well, maybe on linux, with the packages that we don't have yet... Did you miss the Gentoo ebuilds? Isnt it a goal to get other distros to package it too? Just because it did not happen until now, doesnt mean it wont happen some time in the future. May just need more time since Gentoo as source based distro may be a bit better for packages than binary distros. No, it is a goal to package it with private repositories. Having a debian package that is frozen for 3 years is not useful at the present time. And if we have it for linux, why would you like to add additional code for windows (both in the installer and in freenet, which would have to detect the OS and then decide to show the warning or not)? Well, we could do something similar for *nix, no? Launch a suitable privacy enabled browser when the user runs the browse-freenet script? You dont know the user system. While windows user systems may be similar to each others, this is not true for linux. Where would you place that script? How would you check which browser the user wants to use? This idea looks more like the way user handling is done on windows or ubuntu: Expect him to know nothing and try to do everything for him. Might be nice for beginners and if it works, but makes things worse for experienced users, who want to do it different and also makes it harder, if there are problems. Imho you cant beat stupidity. Either users read a message and act the right way or they dont. You cannot prevent them from doing bad things. Additionally, Gentoo is about choice, if there is a warning, the user can choose, with a forcing script, there is no choice, which is a bad idea for this philosophy, therefor i vote against such a script for linux. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On Saturday 16 May 2009 15:02:19 Thomas Sachau wrote: Matthew Toseland schrieb: On Friday 15 May 2009 16:35:40 Thomas Sachau wrote: Matthew Toseland schrieb: On Thursday 14 May 2009 18:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Why would that be bad? What if i dont want to do use the Wizard? Also, if i removed the wizard done line (intentinally or by mistake), a new run would remove my custom settings. With the option, i can just stop the wizard and no harm done. If you know enough to skip the wizard you should shutdown the node, edit the config file and tell the node you have done the wizard! Is there a need for editing the config file? You can set everything with the config section too, but without the i want to do it myself, you cant disable the wizard from the GUI. Related idea: We should maybe tell the user in the installer that they should use a separate browser for Freenet, rather than in the wizard? And then let them choose one, and then use it when they click on the icon to browse Freenet? (#3104) This would produce additional work for people packaging freenet, since they would have to warn the user themselves, while users tend to ignore the output of the package manager. So this would lower the chance of people noticing the request for a different freenet browser/profile and therefor i am against it. I suggest the current way: Warning during first call of the webinterface like it is currently done. Well, maybe on linux, with the packages that we don't have yet... Did you miss the Gentoo ebuilds? Isnt it a goal to get other distros to package it too? Just because it did not happen until now, doesnt mean it wont happen some time in the future. May just need more time since Gentoo as source based distro may be a bit better for packages than binary distros. No, it is a goal to package it with private repositories. Having a debian package that is frozen for 3 years is not useful at the present time. And if we have it for linux, why would you like to add additional code for windows (both in the installer and in freenet, which would have to detect the OS and then decide to show the warning or not)? Well, we could do something similar for *nix, no? Launch a suitable privacy enabled browser when the user runs the browse-freenet script? You dont know the user system. While windows user systems may be similar to each others, this is not true for linux. Where would you place that script? How would you check which browser the user wants to use? This idea looks more like the way user handling is done on windows or ubuntu: Expect him to know nothing and try to do everything for him. Might be nice for beginners and if it works, but makes things worse for experienced users, who want to do it different and also makes it harder, if there are problems. Imho you cant beat stupidity. Either users read a message and act the right way or they dont. You cannot prevent them from doing bad things. Additionally, Gentoo is about choice, if there is a warning, the user can choose, with a forcing script, there is no choice, which is a bad idea for this philosophy, therefor i vote against such a script for linux. Well, we already have a Browse Freenet script on all three platforms. Currently it detects browsers that we know about. You don't have to use it if you don't want to. But we should extend it to use incognito mode if possible, and to favour browsers with such support. I dunno how we can determine whether such a mode works with the particular installed version though... 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] Usability test results
On Friday, 15. May 2009 22:07:34 xor wrote: Wouldn't it take much load off the internet, i.e. small bandwidth connections, if any nodes which are connected via LAN used the LAN for routing requests if possible? I assume that it would also help privacy, because then timing analysis and similar would become much harder, since external nodes can't look into the LAN. To avoid too easy internal traceability, the option of switching to port 8080 or 5223 (jabber server with SSL) (or 80 if started with sufficient rights) would be nice. It would avoid the question what exactly are you running? 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] Usability test results
On Saturday 16 May 2009 23:20:08 Arne Babenhauserheide wrote: On Friday, 15. May 2009 22:07:34 xor wrote: Wouldn't it take much load off the internet, i.e. small bandwidth connections, if any nodes which are connected via LAN used the LAN for routing requests if possible? I assume that it would also help privacy, because then timing analysis and similar would become much harder, since external nodes can't look into the LAN. To avoid too easy internal traceability, the option of switching to port 8080 or 5223 (jabber server with SSL) (or 80 if started with sufficient rights) would be nice. It would avoid the question what exactly are you running? Not much point hiding it if you're broadcasting the existence of nodes via MDNSDiscovery! 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] Usability test results
Matthew Toseland schrieb: On Thursday 14 May 2009 18:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Why would that be bad? What if i dont want to do use the Wizard? Also, if i removed the wizard done line (intentinally or by mistake), a new run would remove my custom settings. With the option, i can just stop the wizard and no harm done. Related idea: We should maybe tell the user in the installer that they should use a separate browser for Freenet, rather than in the wizard? And then let them choose one, and then use it when they click on the icon to browse Freenet? (#3104) This would produce additional work for people packaging freenet, since they would have to warn the user themselves, while users tend to ignore the output of the package manager. So this would lower the chance of people noticing the request for a different freenet browser/profile and therefor i am against it. I suggest the current way: Warning during first call of the webinterface like it is currently done. Well, maybe on linux, with the packages that we don't have yet... Did you miss the Gentoo ebuilds? Isnt it a goal to get other distros to package it too? Just because it did not happen until now, doesnt mean it wont happen some time in the future. May just need more time since Gentoo as source based distro may be a bit better for packages than binary distros. And if we have it for linux, why would you like to add additional code for windows (both in the installer and in freenet, which would have to detect the OS and then decide to show the warning or not)? signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On May 14, 2009, at 5:06 PM, Matthew Toseland wrote: On Thursday 14 May 2009 20:36:31 Robert Hailey wrote: On May 14, 2009, at 12:17 PM, Matthew Toseland wrote: Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) I think that it should be possible to automatically detect this. Specifically, if we detect that our peer has the same external address as us, try and connect locally. Is that a reliable indicator? Not very (what if it changes?) ... we don't want darknet peers to cause us to connect to addresses on our LAN ... otherwise the solution is simply to try the local addresses included ... I agree that we don't want to try the local addresses of ~all~ our peers; local connections are in principal an exception and not cause enough to be sending so much local garbage handshaking traffic (that could give away a freenet node). But I think this is the right way to go... If it is not defined for a given peer (allow/disallow local connections), then we could just calculate the default boolean as his.extAddresses.containsAny(my.extAddresses) if it matches, then there is an excellent chance of it being a local connection (99%). If it changes, that's great! The decision to try local connections would change too! As it's probably a laptop that has floated out of the LAN (and we would want to stop sending handshakes to the local address anyway). At worst we might send a few garbage handshakes to local non- freenet machine until we connect to the node find it's new external address. The reason I think this would solve the problem because (I think) the principal reason that the nodes could not communicate is because the gateway would have to send a packet to itself (many inexpensive or firewalled ones will not). e.g. internal - firewall - external (generally works w/ current countermeasures) internal -- firewall internal -- Does not work (at least for me). So what I propose is really an extension of detecting the problem (the gateway which has the same external ip). Don't know about multihoming, but I presume that this is works in the common case. Once connected to my node, it repeatedly RNFed on the top block of TUFI. Performance with one peer is expected to be poor, but it is worse than IMHO it could be. Some sort of fair sharing scheme ought to allow a darknet peer that isn't doing much to have a few requests accepted while we are rejecting tons of requests from other darknet peers and opennet peers. (#3101) I second that, but I'm not sure as to the best implementation. On the surface this appears to be the same issue as balancing local/ remote requests. i.e. if your node is busy doing everyone else's work, your requests should take clear advantage when you finally get around to clicking a link. Possibly. It is indeed a load balancing problem. Queueing will help, or maybe simulated queueing. I think this conflicts with the current throttling mechanism; piling on requests till one or both nodes say 'enough', Is this how it works now? Yep. To the best of my understanding... Q: How do we determine if we are going to take a remote request? A: If there is room to incur it's expected bandwidth. Premise-1: all chks transfer at an equal rate Result-1: new transfers squeeze bandwidth from other transfers. Result-2: a node will accept any number of transfers until such a point that all of them would go over the maximum allowed transfer time. Effectively making every transfer to the slowest-allowed transfer (not counting local traffic or non-busy nodes). This is why I advocated lowering the slowest transfer time as a general speedup. and if we reserve some space we will not hit our bandwidth goal. Or that requests are actually competing like collisions on a busy ethernet channel rather than having an order. Yes, it is very much like that. Does that mean that the logical alternative is token passing? In fact... guarantee-able request acceptance (token passing), might actually be a logical prerequisite for a fair-queueing system. Interestingly any node can measure how many requests it can accept right now (for bandwidth), but only can guess as to it's peers (by backoff); so then, we may well accept requests which we cannot make good on, because our peers cannot accept them (ethernet collision logic at every hop). One thing that I was playing around with earlier was re-factoring PacketThrottle to be viewed from the queue-side. Rather than sendThrottledPacket blocking till a good time to enqueue a message based on the throttle, that all the packets would be serially available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns the next 'n' packets). Good idea... I
Re: [freenet-dev] Usability test results
On Thursday 14 May 2009 19:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. IMHO the current behavior is a bug though: We have the MDNS plugin, which is installed by default and should automatically (opennet-) connect nodes on a LAN. However it does not work because LAN connections are disallowed by default. 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] Usability test results
xor schrieb: On Thursday 14 May 2009 19:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. IMHO the current behavior is a bug though: We have the MDNS plugin, which is installed by default and should automatically (opennet-) connect nodes on a LAN. However it does not work because LAN connections are disallowed by default. Afaik that plugin is no longer installed by default. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On Friday 15 May 2009 18:37:12 Thomas Sachau wrote: xor schrieb: On Thursday 14 May 2009 19:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. IMHO the current behavior is a bug though: We have the MDNS plugin, which is installed by default and should automatically (opennet-) connect nodes on a LAN. However it does not work because LAN connections are disallowed by default. Afaik that plugin is no longer installed by default. Why not? I like the idea of self-organizing Freenet on LANs very much :) Especially if you consider large public or private LANs where two people running Freenet might not even know each others, so they couldn't get manually connected. 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] Usability test results
On May 15, 2009, at 11:57 AM, xor wrote: On Friday 15 May 2009 18:37:12 Thomas Sachau wrote: xor schrieb: On Thursday 14 May 2009 19:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. IMHO the current behavior is a bug though: We have the MDNS plugin, which is installed by default and should automatically (opennet-) connect nodes on a LAN. However it does not work because LAN connections are disallowed by default. Afaik that plugin is no longer installed by default. Why not? I like the idea of self-organizing Freenet on LANs very much :) Especially if you consider large public or private LANs where two people running Freenet might not even know each others, so they couldn't get manually connected. Hmmm... but does a node want to advertise that we are running freenet? Maybe dependent on the security level setting. In either case, a small network would have major issues if it was not also connected to the large network, and so I think still that automatically detecting locality based on external ip address would help (e.g. a node could preferentially keep any opennet peers that it finds as being local). -- Robert Hailey ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On Friday 15 May 2009 20:04:58 Robert Hailey wrote: On May 15, 2009, at 11:57 AM, xor wrote: On Friday 15 May 2009 18:37:12 Thomas Sachau wrote: xor schrieb: On Thursday 14 May 2009 19:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. IMHO the current behavior is a bug though: We have the MDNS plugin, which is installed by default and should automatically (opennet-) connect nodes on a LAN. However it does not work because LAN connections are disallowed by default. Afaik that plugin is no longer installed by default. Why not? I like the idea of self-organizing Freenet on LANs very much :) Especially if you consider large public or private LANs where two people running Freenet might not even know each others, so they couldn't get manually connected. Hmmm... but does a node want to advertise that we are running freenet? Maybe dependent on the security level setting. The more people confess that they are running Freenet, the more difficult it becomes to blame an individual as guilty for running it. Further, if you run opennet, you are screwed anyway, and MDNS is mostly useful for Opennet. In either case, a small network would have major issues if it was not also connected to the large network, and so I think still that automatically detecting locality based on external ip address would help (e.g. a node could preferentially keep any opennet peers that it finds as being local). Wouldn't it take much load off the internet, i.e. small bandwidth connections, if any nodes which are connected via LAN used the LAN for routing requests if possible? I think the LAN could behave like a single large node, i.e. requests for data which is stored within the LAN would be answered very fast, and much data could be stored if there are many nodes on a LAN. 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] Usability test results
Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. Related idea: We should maybe tell the user in the installer that they should use a separate browser for Freenet, rather than in the wizard? And then let them choose one, and then use it when they click on the icon to browse Freenet? (#3104) This would produce additional work for people packaging freenet, since they would have to warn the user themselves, while users tend to ignore the output of the package manager. So this would lower the chance of people noticing the request for a different freenet browser/profile and therefor i am against it. I suggest the current way: Warning during first call of the webinterface like it is currently done. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On May 14, 2009, at 12:17 PM, Matthew Toseland wrote: Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) I think that it should be possible to automatically detect this. Specifically, if we detect that our peer has the same external address as us, try and connect locally. Is that a reliable indicator? Once connected to my node, it repeatedly RNFed on the top block of TUFI. Performance with one peer is expected to be poor, but it is worse than IMHO it could be. Some sort of fair sharing scheme ought to allow a darknet peer that isn't doing much to have a few requests accepted while we are rejecting tons of requests from other darknet peers and opennet peers. (#3101) I second that, but I'm not sure as to the best implementation. On the surface this appears to be the same issue as balancing local/ remote requests. i.e. if your node is busy doing everyone else's work, your requests should take clear advantage when you finally get around to clicking a link. I think this conflicts with the current throttling mechanism; piling on requests till one or both nodes say 'enough', and if we reserve some space we will not hit our bandwidth goal. Or that requests are actually competing like collisions on a busy ethernet channel rather than having an order. One thing that I was playing around with earlier was re-factoring PacketThrottle to be viewed from the queue-side. Rather than sendThrottledPacket blocking till a good time to enqueue a message based on the throttle, that all the packets would be serially available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns the next 'n' packets). -- Robert Hailey ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On Thursday 14 May 2009 18:35:07 Thomas Sachau wrote: Matthew Toseland schrieb: My observation: Can we get rid of the I will configure it manually choice? And maybe the welcome page? (#3094) You want to force everyone to use the Wizard? Why would that be bad? Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) This is imho not usual, so i would set this to very low priority and only for advanced mode enabled. Hmmm, maybe. Related idea: We should maybe tell the user in the installer that they should use a separate browser for Freenet, rather than in the wizard? And then let them choose one, and then use it when they click on the icon to browse Freenet? (#3104) This would produce additional work for people packaging freenet, since they would have to warn the user themselves, while users tend to ignore the output of the package manager. So this would lower the chance of people noticing the request for a different freenet browser/profile and therefor i am against it. I suggest the current way: Warning during first call of the webinterface like it is currently done. Well, maybe on linux, with the packages that we don't have yet... 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] Usability test results
On Thursday 14 May 2009 20:36:31 Robert Hailey wrote: On May 14, 2009, at 12:17 PM, Matthew Toseland wrote: Because we were both on the same LAN, it did not connect, until I told him to set it to allow local addresses on that peer. There should be a checkbox when adding a noderef, defaulting to on, Friend may be on the same local network as me or something. (#3098) I think that it should be possible to automatically detect this. Specifically, if we detect that our peer has the same external address as us, try and connect locally. Is that a reliable indicator? Not very (what if it changes?) ... we don't want darknet peers to cause us to connect to addresses on our LAN ... otherwise the solution is simply to try the local addresses included ... Once connected to my node, it repeatedly RNFed on the top block of TUFI. Performance with one peer is expected to be poor, but it is worse than IMHO it could be. Some sort of fair sharing scheme ought to allow a darknet peer that isn't doing much to have a few requests accepted while we are rejecting tons of requests from other darknet peers and opennet peers. (#3101) I second that, but I'm not sure as to the best implementation. On the surface this appears to be the same issue as balancing local/ remote requests. i.e. if your node is busy doing everyone else's work, your requests should take clear advantage when you finally get around to clicking a link. Possibly. It is indeed a load balancing problem. Queueing will help, or maybe simulated queueing. I think this conflicts with the current throttling mechanism; piling on requests till one or both nodes say 'enough', Is this how it works now? and if we reserve some space we will not hit our bandwidth goal. Or that requests are actually competing like collisions on a busy ethernet channel rather than having an order. Yes, it is very much like that. One thing that I was playing around with earlier was re-factoring PacketThrottle to be viewed from the queue-side. Rather than sendThrottledPacket blocking till a good time to enqueue a message based on the throttle, that all the packets would be serially available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns the next 'n' packets). Good idea... I thought it was somewhat like that already? It is important in some cases for it to block... 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
