* Matthew Toseland <toad at amphibian.dyndns.org> [2006-07-01 02:33:37]:
> Well, is it entirely clear that we do need VPN support?
No. :)
Freenet is about a DHT ; VPN support seems to be "ahead" of that. It
could be done using plugins ... but should definitly not be part of the
main distribution imho.
And FYI, accessing tun/tap|virtual interfaces from java is almost NOT
possible :
1) java is missing raw sockets
2) you need r00t rights to create the virtual interface,
configure the routing table, the firewall, ...
A plugin using JNI calls could do that though... If we add a dependency
on "pppd" it would be easier (we create ppp over freenet :p)
>
> 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
They send either broadcasts or join a multicast group
> 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...?
They do.
> 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.
We WILL need platform specific 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.
Agreed, but does it worth the additionnal complexity ?
>
> 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.
> _______________________________________________
> 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: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060701/0d4f43b2/attachment.pgp>