-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Toseland wrote:
> 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.

Are you suggesting binding to the address assigned to the peer, grabbing
the traffic sent to that address by another app, and forwarding it
through the tunnel? You'd still have to know which port numbers to bind
to on each address though, right? So it would only be as convenient as
manual port forwarding. And wouldn't you need at least two threads per
forwarded port?

I'm not saying it's impossible, but it sounds a lot more heavyweight
than OpenVPN.

> The
> only worry is that tunneling TCP may not be entirely straightforward as
> we don't have any similar streaming code at present.

Even when we do, you have to be careful with timers:

http://sites.inka.de/~W1011/devel/tcp-tcp.html

If we want to encapsulate IP packets inside FNP messages inside IP
packets, the maximum packet size inside the tunnel is going to be pretty
small. Not all applications cope well with that, even if they should.

Here's an alternative suggestion: set up OpenVPN tunnels to all our
peers, then send Freenet traffic through the VPN along with any other
traffic the user wants to forward. That way we avoid encapsulating IP
packets inside Freenet messages, and we avoid TCP-over-TCP. Peers'
addresses are discovered from their ARKs, but NAT traversal is handled
by OpenVPN. This has the added advantage that Freenet traffic looks more
like normal VPN traffic.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEpjbJyua14OQlJ3sRAvv3AJ9OzIQli+GKKNNQFEdGDNZjzEYL4QCgqNZ9
PGKIW9PLNrX7X00jcWYgSI4=
=8b2O
-----END PGP SIGNATURE-----

Reply via email to