Well, is it entirely clear that we do need VPN support? Do games/Network Neighbourhood/etc send packets to a specific interface address to discover servers on the LAN, or do they just broadcast (255.255.255.255)? I suppose they would broadcast. In which case, does loopback receive these broadcasts? How do they receive responses? Do they bind to a specific interface? If so, how can Hamatchi work when there is both a physical LAN and a virtual one? I doubt that most games would look for every interface with an address that looks like a LAN address, and bind to each...? If we can receive the broadcasts on loopback, and if we can receive the responses to them on loopback, then we may indeed be able to do this without any nasty platform specific VPN code. However, if the VPN code is freely available under a suitable license for all interesting platforms, then it's not necessarily a big deal if we can't.
Apart from network discovery, it is entirely possible to bind to addresses in the loopback range, assign permanent IPs to peers, and edit the hosts.txt file on windows or /etc/hosts on linux to include permanent name entries. Without any nasty platform specific code. The only worry is that tunneling TCP may not be entirely straightforward as we don't have any similar streaming code at present. Tunneling UDP is fairly trivial. 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/20060701/bc08c82d/attachment.pgp>
