Well, how do we do this on Windows? I have some idea how we'd do it on Linux - the VPN driver, or the user-space networking driver, provides a module you can load to provide a fake network interface from userspace. But what on earth would we do on Windows?
I do think this is a good idea if we can do it. But it's not easy to do! Also, will games' auto-discovery still work, if there is a real LAN and a virtual one as well? Will they broadcast to both of them? On Fri, Jun 30, 2006 at 04:47:04PM -0400, Colin Davis wrote: > > > >I'm not entirely sure why this would need to be done outside of > >Java... > >Can't we already bind to an infinate number of IP addresses? If we > >pick > >IPaddress to bind to that aren't taken, such as 172.100.100.* we > >should > >be able to bind to those without an issue. > > I agree with the rest of my post, and think that Hamachi-style > functionality would be THE killer app, but I don't know what I was > smoking when I wrote that part. > Of course we would need some sort of .lib per-system to bind to IP > addresses. It's trivial to do, and we're already using .libs for > native acceleration. I think it's acceptable, considering if it's not > there, or can't load, freenet still works, the Hamachi sharing just > doesn't. > > > Please consider it. I know implementing a VPN-style connection is a > pain, but since we ALREADY have connections to those people that span > NATs, it's not as hard as it otherwise would be. > Doing so will ENSURE darknet is VERY popular- There are lots of > Filesharing/IM apps- There aren't any OSS which do this (easily). > > -Colin > > > > > >> > >> > >>There are OSS apps that do this, it's just that it's difficult to > >>set up > >>as what you are doing is creating a VPN. That would be extremely > >>difficult to do over Java. > >> > >>However, the idea of sharing services out to your darknet peers is > >>possible, if it is sufficiently useful. Certainly exposing samba > >>shares > >>or other TCP-based services is possible (if they are allowed to > >>localhost or LAN already). > >> > >>As far as UDP-based games go, isn't it always going to perform > >>better to > >>connect directly to the IP address of your friend? Admittedly you > >>have > >>to password the server, and find their IP address... I wonder if > >>there's > >>something in the idea of dyndns over freenet (as opposed to ARKs; > >>make > >>toad.freenet resolve via a local lookup of the ARK or the > >>connection to > >>toad's current IP address)... we could have the node insert (and > >>keep up > >>to date) lines for your darknet neighbours in hosts.txt. :) > >> > >>It would be possible to tunnel generically as with a VPN, and make it > >>look like a LAN. However it would be very difficult (it would > >>definitely > >>require external non-java code, and on windows that would have to be > >>nasty low level code probably requiring the DDK; on linux it might > >>require > >>loading the standard kernel VPN module), and it would be slower than > >>direct connections. In exchange it solves all the authentication > >>problems. > >> > >>Anyone have any more ideas for darknet value-add? > >> > >>On Fri, Jun 30, 2006 at 01:50:40PM -0400, Colin Davis wrote: > >>>I think this is a Wonderful line of thinking. > >>>Reward good behavior, rather than punishing bad. > >>> > >>>I think responding to Jabber commands would go a long way here- > >>>It gives > >>>people a Waste-like IM system, which is a great idea. > >>> > >>> > >>>I don't think it's a killer-app, though. > >>> > >>>What would make Freenet a Killer App, and encourage a LOT of > >>>installations, and encourage people to make peers is including > >>>Hamachi-style functionality. http://www.hamachi.cc/ > >>> > >>>Essentially, since we already have a connection to them, let us > >>>forward > >>>OTHER types of traffic over it. > >>> > >>>I use iTunes, and so does my friend "Bob". Neither of us can play > >>>each > >>>other's shared library, since they are on different physical > >>>LANs- What > >>>Hamachi lets you do is instantly create a virtual network between > >>>everyone's who's connected to one "Network Name". > >>> > >>>After you did this, you could play Multiplayer Games, do VOIP, etc.. > >>>Essentially, make it so that you can piggy-back any other program > >>>over > >>>freenet's links. > >>> > >>>So for example, Freenet could create virtual IP addresses locally- > >>>192.168.135.X, where X is number of the friend in the darknet > >connection... > >>> > >>> > >>>So, for example, if I had 5 darknet friends- > >>> > >>>1- SinnerG > >>>2- Aum > >>>3- Toad > >>>4- Sanity > >>>5- Hobx > >>> > >>>If I want to Open a Quake3 game with SinnerG, I could connect to > >>>192.168.135.1 > >>>If I want to share files with Aum, I could go to smb:\\192.168.135.2 > >>>If I want to ftp to Toad, I can open a ftp connection to > >>>192.168.135.3 > >>> > >>>Etc. > >>> > >>>Right now, there is NO OSS app that does this- But with the > >>>infrastructure freenet has, it wouldn't be that hard to > >>>implement, and > >>>it would make people LOVE darknet connections, but ONLY to their > >>>friends, not to people they don't know. > >>> > >>> > >>>In other words- It's perfect. > >>> > >>>;) > >>> > >>>-Colin > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>>On Fri, Jun 30, 2006 at 01:47:01PM +0200, Oskar Sandberg wrote: > >>>>>Ian Clarke wrote: > >>>>>>-----BEGIN PGP SIGNED MESSAGE----- > >>>>>>Hash: SHA1 > >>>>>> > >>>>>>I don't think we necessarily have to prevent location swapping on > >>>>>>opennet nodes, the destination sampling approach seems pretty > >robust, > >>>>>>and as the network stabilizes, the number of location swaps > >should > >>>>>>decrease. > >>>>> > >>>>>I don't think this matters either. A much bigger concern is that > >the > >>>>>network could end up largely split into two - very few "open" > >>>>>nodes > >>>>>talking to dark ones, and vice versa. For it to work, people who > >are > >>>>>open would also have to want to authenticate people who don't > >directly. > >>>> > >>>>In other words we need to figure out a system of incentives to > >>>>make it > >>>>extremely attractive, as well as easy, to add darknet peers. > >>>>There is > >>>>absolutely nothing wrong with incentivising the behaviours which > >>>>will > >>>>ensure the network's survival. We have to do this to some degree > >in e.g. > >>>>load balancing, this is no different. > >>>> > >>>>Here's my thoughts: > >>>> > >>>>1. Opennet takes ages to bootstrap. It has constant connection > >>>>churn. > >>>>While this can be a strength, it can also be a weakness. Darknet > >offers > >>>>some level of stability. > >>>> > >>>>2. We can provide some level of local "sharing". We can share > >bookmarks, > >>>>and possibly file indexes, with our direct peers. We can send text > >>>>messages to them, or files; we can integrate with Jabber perhaps. > >>>> > >>>>3. Significantly increased security. We can have a "trust levels" > >>>>system. If you have enough true-darknet connections then locally > >>>>generated requests can be limited to true-darknet connections. > >>>> > >>>>4. More security: I believe it will be extremely difficult to > >implement > >>>>premix routing in any meaningful and safe way on opennet. > >>>>Certainly it > >>>>will require completely different structures. Both premix > >>>>routing and > >>>>swap enforcement *require* darknet AFAICS. > >>>> > >>>>5. Preferential treatment. True darknet nodes will tend to have > >>>>fewer > >>>>connections and therefore more traffic can be handled from each > >>>>connection. But we can go beyond this: While we should not misroute > >>>>requests we have accepted to our darknet peers, there is nothing > >>>>wrong > >>>>with accepting more requests from them, if they want to send more > >>>>requests. Load balancing will then adjust the input load > >>>>accordingly > >>>>(more darknet requests allowed, less opennet ones). > >>>> > >>>>Any other ways in which darknet is better, or means by which we can > >>>>favour it without breaking opennet? > >>>>> > >>>>>A problem, in general, with this whole thing is that the > >incentives for > >>>>>connecting to people are too small. It is hard to convince > >people that > >>>>>they ought to go through the trouble of adding more then a > >neighbor or > >>>>>two, if the only reason is that it is healthy for the network > >>>>>(when > >>>they > >>>>>may not notice much difference themselves). > >>>> > >>>>Yes. > >>>>> > >>>>>When I first envisioned an applications of this type of Darknet, I > >>>>>thought of it much more in the context of a IM/file sharing > >application > >>>>>then Freenet. In such a system, people would have have > >>>>>motivation to > >>>add > >>>>>"buddies" (presense, being able to surf their share directly, etc) > >>>which > >>>>>they don't in Freenet... > >>>> > >>>>Why can we not have Thaw share its index files with the adjacent > >nodes? > >>>>We could provide FCP support for local messaging. > >>>>> > >>>>>// oskar > >>>>-- > >>>>Matthew J Toseland - toad at amphibian.dyndns.org > >>>>Freenet Project Official Codemonkey - http://freenetproject.org/ > >>>>ICTHUS - Nothing is impossible. Our Boss says so. > >>>> > >>>> > >>> > >>>-- > >>> > >>>_______________________________________________ > >>>Devl mailing list > >>>Devl at freenetproject.org > >>>http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >>> > >> > >>-- > >>Matthew J Toseland - toad at amphibian.dyndns.org > >>Freenet Project Official Codemonkey - http://freenetproject.org/ > >>ICTHUS - Nothing is impossible. Our Boss says so. > >> > >> > > > >-- > > > >_______________________________________________ > >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 > -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060630/9f4be139/attachment.pgp>
